Often splits several seconds after detected split points
utility to split mp3, ogg vorbis and FLAC files without decoding
Brought to you by:
io_alex_2004,
mtrotta
Menu
▾
▴
#86 Often splits several seconds after detected split points
When I was using audacity to find split points manually mp3splt-gtk worked OK, but it often goes wrong when using the silence detection. When I click on the LiveP button it sometimes appears as if the split is about 10 seconds early so I've been adjusting them manually. But when I played back the split files I found that some of the splits were 10 seconds too late, so the LiveP button must have been starting about 10 seconds earlier than the splits.
Hello,
thank you for the feedback :)
What version of mp3splt-gtk are you using ?
10 seconds is huge. Is this with mp3 or ogg files ?
On what operating system have you used it ?
--
Alex
I'm using the Debian package 0.5.7a.unstable (downloaded from SF because the deb repos have an older version) on Debian unstable amd64. I've been using it on audio books in mp3 format. I was using a minimum silence length setting of about 8 secs, but I might have been using slightly different values on different occasions.. I guess I could send or upload a problem file somewhere, but they're quite large, and there's the copyright issue :-(.
This mostly happends when the input file contains synchronisation errors due to audio files concatenations.
If this happens again, please try splitting the file with the 'Error mode' first; this will split the file according to synchronisation errors. Then, on the newly created files, you should not have differences between the player and the split files.
I am considering this issue postponed.
You can find debian repositories and downloads of the latest version (0.6.1) here:
http://mp3splt.sourceforge.net/mp3splt_page/downloads.php
Please repost here if the issue still occurs.
Hello Alex, I can still reproduce a 1.5 second gap between the quick preview (LiveP) and the SplitPreview (SplitP) - even on files where I ran the check error mode before. So this means I have to calculate some nasty offset in the markers to have it cut right. I was testing this on the packages from the Debian/Squeeze repository, the latest Squeeze packages from your site and the Debian/Lenny packages from your site. Results are: in Lenny the preview -> cut offset was minimal (about 0.3 secs) now it's significant (1.5 secs) thus annoying. Attached is the output of "dpkg -l | grep splt" so you get the idea of my software selection:
Lenny: dpkg -l | grep splt
ii libmp3splt 0.5.9.lenny
ii mp3splt 2.2.8.lenny
ii mp3splt-gtk 0.5.9.lenny
Squeeze: dpkg -l | grep splt
ii libmp3splt0 0.6.1a.squeeze
ii libmp3splt0-mp3 0.6.1a.squeeze
ii libmp3splt0-ogg 0.6.1a.squeeze
ii mp3splt 2.3a.squeeze
ii mp3splt-gtk 0.6.1a.squeeze
Regards, Tuxo
Hello again Alex,
Since I figured out identical splitting marks return the same cut offset using mp3splt from Lenny and Squeeze, I came along the playback offset issues caused by audacious - those where reported by Ron last summer [1]
Turns out these playback issues still can be reproduced in your latest Squeeze packages using the libmad library of debian/multimedia on a file encoded with 128k CBR. If I change the output to gstreamer the playback preview and the actual cut are in the usual 1/3 second offset again, so that's fine to work with.
So I'll stick with gstreamer as playback device for now. Is it somehow possible to have gstreamer share the audio device with other playback applications? I noticed I have to close all open audio players to use the gstreamer playback. Usually it doesn't matter if other playback apps are kept open. They share the device and you usually have them just stop the playback, not close the app.
If you have some more patchwork I can test to get the audacious playback "back on track" again, please point me to the right place, so I can build if from source.
Cheers, Tuxo
[1] http://old.nabble.com/Re%3A-cumulative-error-in-mp3splt-gtk-time-cues-with-audacious-td29058979.html
Hello,
is it possible to send me a small sample, so that I investigate the issue ?
You can send it to me at
m AT ioalex.net
--
Alex
Hello Tuxo,
it looks like audacious has a different seeking than madplay.
If I check the created output file and play the original file starting at the splitpoint using madplay, they are exactly the same.
You can check it using the following command line :
- for 55 minutes, 48 seconds and 49 hundreths:
madplay -s 00:55:48.490 original_input_file.mp3
Now we should see why the seeking is that different ...
For gstreamer, you shouldn't have to close other applications.
I'm not a gstreamer expert, but I can play even several gstreamer applications at the same time (mp3splt-gtk & totem for example).
I will post here if I found out more ...
It appears that the audacious libmad plugin (called MPEG Audio Plugin - madplug.so) is seeking by guessing.
The FFaudio Plugin seeks better.
Can you please try changing the decoder from the audacious preferences (Preferences->Plugins->Decoders):
- uncheck MPEG Audio Plugin and all other decoders (just to check)
- check FFaudio Plugin
- retest with audacious
?
hello alex
Thanks for testing this, I checked with ffaudio plugin and the playback still is off track (SplitP, LiveP differ) so the export ist not what I listened to. I'll try to upload a sample somewhere (dropbox or rapidshare) and send you a link.
regards Tuxo
Hello,
I am trying to split this mp3 (German language course for Czechs). There is cca 9 seconds piano intermezzo beetween lessons, but I must set a splitpoint before this intermezzo to catch a lesson at beginning in the mp3 created.
The time difference is small for the first lesson but it grows with every next lesson, so it seems to me like some sample rate mismatch.
I am using Debian Wheezy, KDE, mp3splt-gtk 0.8.2, and gstreamer player.
I have got the same error behavior with mp3splt-gtk 0.7.2 from the official Wheezy repo.
Petr
Hello Ptr,
thank you for this example.
I have downloaded the file and I will take a look.
--
Alex
I mean *Petr
Petr, please use the 'frame mode' from the preferences.
Make sure to check from the top menu
File->Preferences->Frame mode (useful for mp3 VBR) (mp3 only)
and then retry.
I will have to show a note or something for this mode.
Hello Alex,
it works like a charm in the frame mode.
Isn't this mp3 a 128kbps CBR?
Thank you very much, I enjoy working with it now.
Petr
Well, all software I tried says it's 128kbps CBR.
I will have to investigate to see why it's not working without frame mode.
Last edit: Munteanu Alexandru 2013-07-07
Hi - new here. but I think my bug (using mp3splt-gtk 0.9) is related to the above. Have split successfully before but in my most recent file relationship between time shown and sound event in player variable - seems to depend on how much I track backwards and forwards in the file. As a result, beginning and end of split file (played in VLC) is several seconds out from where I positioned split points - beginning is too late, and end is too early. Have tried setting frame mode, but no difference. Ended up splitting by trail and error - very frustrating. Any suggestions? (Otherwise very happy with program - thank you!)
Thank you for the feedback Andrew.
I never encountered this problem when the 'Frame mode' was checked.
Is there any way you could send me a part of the file or the whole file you are trying to split ?
If you don't want to post here, you can send it to me at m@ioalex.net
Btw, what audio player do you use with mp3splt-gtk and on what operating system ?
Still need some more information on this issue ...
Hi there, I too have mismatched between the mp3 file and the selected split points. I'm a on a linux 64bit ubuntustudio 14.04 system, and have downloaded this file from youtube https://www.youtube.com/watch?v=v6qDYd2G8RY using youtude-dl (it uses avconv to extract the audio data).
The final mp3 file is
I listened to the file through the gstream player and inserted my markers. After the split I realised there are differences between the start point of the mp3 and each split point, (on average 2 seconds) - mp3 was always starting earlier than designated in the split file.
I also tried with audacious player, and I also tried reducing the 200msec delay of the player. Everytime I re-tried to find the right split points. Truth is there were the same, but the mp3 file were always wrong.
You can grab the cue file that I created from https://pithos.okeanos.grnet.gr/public/K70CDPosaCy3va6fCuko3
I'll be following this thread in case you need any clarifications
Hi,
I am downloading and extracting the audio using youtube-dl, but can you please tell me what version of mp3splt-gtk are you using ?
I have already downloaded the .cue file.
Thank you.
--
Alex
Hi there.
I've just stumbled across this thread since I too am having problems with the split points in an MP3 file not being correctly placed. Mine is an mp3 converted from a youtube downloaded mp4.
I used mp3splt-gtk to examine the file and place the split points, however when playing the split files with Amarok it becomes apparent that they were way out of sync with what was played back using mp3splt-gtk. I've tried splitting with Frame mode both on and off, but it doesn't seem to make a difference.
In addition to the above, there is a loud artefact at the start of each split file which, frankly, makes them useless. I'll be following this thread with interest to see if you can shed any light on the issue. This would be an excellent program, if only I could get it to work as intended, so thanks for your work on it so far.
Obviously, I can provide access to the mp3 and .cue files if you would like to try to replicate the problem.
Tim
Ubuntu 14.10,
Libmp3splt 0.9.2
Mp3splt 2.6.2
Mp3splt-gtk 0.9.2
Hi there,
Munteanu Alexandru . I'm the anonymous user that sent the .cue file before.
I have downloaded mp3splt-gtk from the repositories and the version that I run is 0.7.2.
same version of libmp3splt
I tried the same file and cue in a slackware ssystem with mp3splt-gtk 0.9 and now the split mp3 files start a bit later than the locations i have marked in the cue file