Issue #32 resolved

`Mp3AudioInfo.time_secs` incorrect for MPEG2 and MPEG2.5 files

Jason Penney
created an issue

TIME_PER_FRAME_TABLE is correct for MPEG 1, but incorrect for 2 and 2.5. Perhaps it should be two dimensional?

#                              L1    L2    L3
TIME_PER_FRAME_TABLE = ((None, 384, 1152, 1152), # MPEG 1
                        (None, 384, 1152, 576),  # MPEG 2
                        (None, 385, 1152, 576))  # MPEG 2.5

See mpg123 src/common.c.

Comments (15)

  1. Travis Shirk repo owner

    Hey Jason,

    Do you have a file that demonstrates this problem, where the eyeD3 time does not match the wall clock time? Why I ask is I made a test patch (attached) to make use of this table and ran it against my entire collection and looked at the diffs. For example:

    Sample File

    -Time: 06:39    MPEG2, Layer III    [ 56 kb/s @ 22050 Hz - Joint stereo ]
    +Time: 03:19    MPEG2, Layer III    [ 56 kb/s @ 22050 Hz - Joint stereo ]
    

    The - is old, and the + is patched. The value 06:39 is correct. mplayer and easytag print the same, and the wall clock says it as I listened. The total diff of changed times is large, but a manual check of a small sampling show the eyeD3 times to be correct.

  2. Travis Shirk repo owner

    Meanwhile subsonic gets times different than both listed above, and cuts off the track after very short times. Preventing me from listening to this excellent live set. Playing the link above in Chrome does play completely and shows 06:39.

  3. Jason Penney reporter

    I took a 30 second wav file, and did:

    for x in 8 12 11.025 16 24 22.05 32 44.1 48; do
        lame sample.wav --resample $x -V0 "$(printf "%06.3f.mp3" $x)"
    done
    

    When I checked those with eyeD3 I get:

    $ eyed3 *mp3 2>/dev/null |grep ^Time 
    Time: 01:00 MPEG2, Layer III    [ ~28 kb/s @ 8000 Hz - Joint stereo ]
    Time: 01:00 MPEG2, Layer III    [ ~31 kb/s @ 11025 Hz - Joint stereo ]
    Time: 01:00 MPEG2, Layer III    [ ~32 kb/s @ 12000 Hz - Joint stereo ]
    Time: 01:00 MPEG2, Layer III    [ ~53 kb/s @ 16000 Hz - Joint stereo ]
    Time: 01:00 MPEG2, Layer III    [ ~73 kb/s @ 22050 Hz - Joint stereo ]
    Time: 01:00 MPEG2, Layer III    [ ~79 kb/s @ 24000 Hz - Joint stereo ]
    Time: 00:30 MPEG1, Layer III    [ ~212 kb/s @ 32000 Hz - Joint stereo ]
    Time: 00:30 MPEG1, Layer III    [ ~245 kb/s @ 44100 Hz - Joint stereo ]
    Time: 00:30 MPEG1, Layer III    [ ~251 kb/s @ 48000 Hz - Joint stereo ]
    

    The files all play for 30 seconds, and soxi shows them all being (about) the same length:

    $ for x in *mp3; do echo "${x}: $(soxi -D "$x")"; done
    08.000.mp3: 30.168000
    11.025.mp3: 30.145034
    12.000.mp3: 30.096000
    16.000.mp3: 30.096000
    22.050.mp3: 30.065986
    24.000.mp3: 30.048000
    32.000.mp3: 30.060000
    44.100.mp3: 30.040000
    48.000.mp3: 30.024000
    
  4. Jason Penney reporter

    I do the correct result with your sample file. It seems to be related to CBR/VBR. CBR files seem to be listing with the correct time, and VBR files are showing up twice as long.

  5. Jason Penney reporter

    I generated a set of files (all possible bitrates + VBR, sample rates, stereo modes) and ran tests against them verifying eyeD3 was reporting them correctly (plus the duration test). These are the passing results.

  6. Travis Shirk repo owner

    Revisited the table of samples (called time before) per frame table with this patch and the test set/script from Jason. Current HEAD has 30 failures (of 585) with the patch the count goes to 330.

    The interesting thing is is looks like the table patch solves the 30 failures from the unpatched version, but introduces so many more. hmmmm

  7. Log in to comment