search

eharris / mp3splt

mp3splt/mp3splt-gtk/libmp3splt are tools and a library to allow frame-accurate splitting and joining of encoded audio files without requiring decoding or re-encoding. This project was migrated from the abandoned Sourceforge project on 2020-09-13.
0 stars 0 forks source link

split files are truncated when played in xine #197

Open eharris opened 4 years ago

eharris commented 4 years ago

Imported from SourceForge on 2020-09-13 05:04:47 Created by oliverhenshaw on 2008-12-13 21:11:04 Original: https://sourceforge.net/p/mp3splt/bugs/64

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

eharris commented 4 years ago

Imported from SourceForge on 2020-09-13 05:04:48 Created by oliverhenshaw on 2008-12-13 21:12:54 Original: https://sourceforge.net/p/mp3splt/bugs/64/#197a

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

Attachments:

eharris commented 4 years ago

Imported from SourceForge on 2020-09-13 05:04:50 Created by oliverhenshaw on 2008-12-13 21:15:22 Original: https://sourceforge.net/p/mp3splt/bugs/64/#d5e5

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

Attachments:

eharris commented 4 years ago

Imported from SourceForge on 2020-09-13 05:04:53 Created by io_alex_2004 on 2009-01-06 22:13:02 Original: https://sourceforge.net/p/mp3splt/bugs/64/#d9cd

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

eharris commented 4 years ago

Imported from SourceForge on 2020-09-13 05:04:56 Created by io_alex_2004 on 2011-05-30 21:12:38 Original: https://sourceforge.net/p/mp3splt/bugs/64/#e44f

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

eharris commented 4 years ago

Imported from SourceForge on 2020-09-13 05:04:59 Created by io_alex_2004 on 2011-06-04 20:46:04 Original: https://sourceforge.net/p/mp3splt/bugs/64/#ca83

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.