Silence detection completely off (mp3splt-gtk 0.9)
utility to split mp3, ogg vorbis and FLAC files without decoding
Brought to you by:
io_alex_2004,
mtrotta
Menu
▾
▴
#164 Silence detection completely off (mp3splt-gtk 0.9)
I have used mp3splt-gtk 0.7.1 under Ubuntu 12.04 before and was so pleased with the results that I decided to upgrade to the latest and greatest 0.9 from the sourceforge repositories. Unfortunately the very next recording I tried to split by automatic silence detection had split points that were off by a several seconds at almost every single split. The silence is audibly quite obvious to detect so I must assume some things are not working as they should.
I tried several times and consistently got the same results: Among 10 split points, 2 were erroneous (close to another one but in the midst of sound), 1 was 4 seconds too late, 3 were late by 4s and 10s (twice).
Unfortunately, I deleted the old files I successfully treated with 0.7.1, so I cannot compare those. Furthermore I do not seem to know how to downgrade back to 0.7.1 (simply deleting the deb-entry for apt-get sources does not seem to work). The best help I can offer for the moment is to provide the file in question. I would be glad to help more if told what to do.
Sincerely,
Stefan Mueller, Switzerland
Hello,
thank you for reporting the issue.
You can send me the file to m@ioalex.net.
As stated in my mail, the file that I downloaded splits correctly for me.
I suggested a potential problem with the installation.
--
Alex
Eventually, you can also try mp3splt-gtk version 0.9.1 that I just released.
If you can reproduce with a more recent version and want to provide more informations, please post here.
Many thanks for getting back and many, many appologies for not responding any earlier! I have been incredibly busy and could not find the time to explain what seems to go wrong. I just saw your posting and studied your e-mail response again.
As far as I can tell from your graph, you do get the same results as I. So there seems to be nothing wrong with the software installation. Probably my initial problem statement was mis-leading, so let me try again:
. With 0.7.1 I had treated several audio files and the results all were fine.
. I then upgraded to 0.9 and treated the audio file in question. The split points are audibly wrong as I had explained in my mail (several seconds off; full details in my mail).
. My conclusion/suspicion was that the silence detection of 0.9 was broken. The files I had successfully treated before with 0.7.1, had been deleted, so unfortunately I could test them against 0.9.
. I understand that you do get the same erroneous split points. So I conclude that there is nothing wrong with my installation but that the splitting algorithm fails for this file.
This leads me to the question if there is something very specific about this file or if this might hint to a problem with the algorithm or maybe my handling of its settings. From my point of view there is nothing that distinguishes that file from the previously treated ones (same digital audio source, same recording procedure). I had planned to investigate by myself but have not been able to work on any other audio files. If nothing more, that file might provide a test case for improvements in the silence detection algorithm.
Cheers!
Stefan Mueller, Switzerland
Forgot to add the information you requested per mail:
DISTRIB_DESCRIPTION="Ubuntu 12.04.4 LTS"
stefan@c214:~$ uname -a
Linux c214 3.2.0-61-generic-pae #92-Ubuntu SMP Tue Apr 1 00:10:04 UTC 2014 i686 i686 i386 GNU/Linux
stefan@c214:~$ dpkg -l | grep mp3splt
ii libmp3splt0 0.9.0.precise library for splitting MP3 and Ogg Vorbis files
ii libmp3splt0-flac 0.9.0.precise Flac plugin for mp3splt
ii libmp3splt0-mp3 0.9.0.precise MP3 plugin for mp3splt
ii libmp3splt0-ogg 0.9.0.precise Ogg Vorbis plugin for mp3splt
ii mp3splt 2.6.precise Command line program that splits MP3 and Ogg Vorbis files without reencoding
ii mp3splt-gtk 0.9.precise Gnome application for lossless linear editing of audio files
Don't worry for the late reply.
I am very confused because the audio of the split files seems correct to me.
I still have the file and can send you back if you wish.
I still have that file available too. Only the ones I had treated before with 0.7 went missing.
From what I have seen in your screen shot we do get the same split points. Mine lie at
00:00:00 00:09:02 04:28:07 11:11:56 17:21:48 20:24:02 27:45:36 32:26:07 32:29:00 37:19:50 42:02:26 45:15:58 47:00:05
and produce twelve files of the following sizes:
157K 4.2M 6.6M 6.2M 3.1M 8.3M 4.7M 58K 5.1M 4.9M 3.3M 1.8M
I have spent now more than half an hour verifying that the splits indeed are off, wondering all the while why anyone would claim that the results are fine. -- And now, I finally got the answer!
When I play the files in any media player like Banshee, they indeed are absolutely fine. However, playing them in the built-in player of mp3splt-gtk was what lead me to conclude that the split points were off. Indeed, there they do lie consistently off the audible breaks. The attached screenshot was taken at such a point where the split point lies at 27:45:36 whereas the audible split happens at around 27:55.
So the problem certainly is not with the splitting itself but with the built-in player. Or do I mis-understand that player?
Thank you very much for your testing.
I really appreciate your help.
Opening the file with audacity shows the silence at the exact point where mp3splt-gtk is seeing it - like in the attached screenshot.
I tried to "seek" to that time (27:45) with another player and it has the same issue as the built-in player.
So I believe that this is an issue with the seeking of the mp3 file.
Players are wrongly seeking the file.
Hmm ...
If you are familiar with the command line, madplay seems to seek "fine".
madplay -s 0:27:45 Full.mp3
I don't understand yet why.
I don't know much about multimedia formats at all but I wonder if this might be specific to that particular file or if it is a general issue. What initially lead me to believe there was an error in mp3splt-gtk was that, if I remember correctly, all the previous files (treated with 0.7) had played as expected in the built-in player. As far as I can tell I had always applied the same work-flow.
I am going to test some more files with 0.9 as soon as I find time and see if I run into similar difficulties. Maybe the issue is due to a possible fault in the file and not related to mp3splt-gtk.
I'm not sure that we need to fix something here any more ...
Setting this ticket to pending meanwhile.
Alexandru,
I am so sorry to have left this ticket open for so long! Indeed, I had intended to get back to the case but never did because I always had other issues to run after. So I would say that this ticket has become obsolete.
Many thanks for your work on this software! It has proven useful many times, although I am only a occasional user.
Cheers!
Stefan
No problem :)
--
Alex