Menu

#64 split files are truncated when played in xine

open
nobody
None
1
2012-09-12
2008-12-13
No

I split an interview from a longer mp3 file. When playing it back with amarok-xine I noticed that the last portion was truncated. It played fully with both mplayer and totem-gstreamer but was truncated when played with xine. To exhibit this bug I produced several mp3 clips of the end of the interview with mp3splt and with audacity.

The end point of each clip is identical, and was chosen in audacity using the waveform as a guide (the same timestamp was used in mp3splt). The clips contain the very last seconds of an interview, with a short "bye" followed by an even shorter laugh. The fragment of laughter is very clearly truncated or missing when played with xine. The starting point of the clips are chosen so that the clips last 1, 2, 3 and 4 seconds (while ending at the same point).

The clips produced using audacity sound correct in mplayer, totem and xine; while the clips produced using mp3splt are truncated in xine, but sound correct in mplayer and totem. The different lengths of clip sound different in xine, in particular the two second trick is quite truncated in xine (the laughter is completely missing).

Software used (on fedora 8):
mplayer-1.0-0.97.20080818svn.fc8.1
xine-lib-1.1.15-1.fc8
totem-2.20.1-2.fc8
ibmad-0.15.1b-8.fc8

libmp3splt-0.5.2, mp3splt-2.2.1, mp3splt-gtk-0.5.2 compiled from source

Discussion

  • Oliver Henshaw

    Oliver Henshaw - 2008-12-13

    Clips produced in audacity with length 1, 2, 3, 4 seconds

     
  • Oliver Henshaw

    Oliver Henshaw - 2008-12-13

    Clips produced in mp3splt with length 1, 2, 3, 4 seconds (and with length 0.4, 0.5, 0.6, 0.7 seconds)

     
  • Munteanu Alexandru

    Hello,

    thank you for reporting this issue.

    I have tested a bit, but I have both mp3splt and audacity files "truncated" at the end
    with xine-lib 1.1.15-r1 (amarok 1.4.10 - using kde 3.5.9).

    You can also try splitting the same 4 second portion with the original mp3splt v2.1c
    which does not depends on libmp3splt, and see if you obtain the same result :
    https://sourceforge.net/project/showfiles.php?group_id=55130&package_id=49997

    What I found strange is that when looking with audacity at the audacity produced file
    and at the mp3splt produced file, the mp3splt one is slightly "moved" to the right.
    Is it possible to attach some 7 seconds portion containing the clip produced having
    4 seconds ?

    --
    Alex

     
  • Munteanu Alexandru

    This appears with the mad xine mp3 decoder - it works well with the ffmpeg decoder.
    I will have to investigate ...

     
  • Munteanu Alexandru

    It is not easy to find out if this is a mp3splt bug or not.
    Without the original input file, it is not possible to compare and see if the frames are the same on the output files.
    I was not focused on comparing the audacity created clips with the mp3splt ones, since audacity re-encodes the audio data, while mp3splt doesn't.

    However, I tried to find out why the audio output is different on the mp3splt created file, using different decoders.
    I haven't found out the answer yet, but I have posted a mail on the mad-dev mailing list, hoping to get some help:
    http://www.mars.org/pipermail/mad-dev/2011-June/001423.html

    I will repost here if I have more information about this.