Version: 1.3.9 (using KDE 3.5.2, Kubuntu Package 4:3.5.2-0ubuntu18 dapper) Compiler: Target: x86_64-linux-gnu OS: Linux (x86_64) release 2.6.15-23-amd64-k8 When playing a long .ogg Song (Nirvana-Something in the Way, xmms reports a length of 20:35), it's length is not displayed correctly. Amarok shows 16:09 for the song, the slider down below shows 16:11. KDE seems to be buggy in this respect too, as Konqueror File Properties show only 13:07 for that song. Shorter songs encoded the exact same way (same tools, same quality) seem to be consistent between xmms and kde/amarok.
I have similar problems. My music collection is quite large due to recording with StreamRipper. The song length of a couple of songs is caculated incorrectly. I do not think it is a problem of how long a song is. Fact is that XMMS can calculate the song correctly. I have also observed that KDE and amaroK must use the same algorithm to detect the song length. Whenever amarok displays wrong information KDE also displays wrong information. I really do not want to give up amarok. It is a excellent application. But I expect that amarok is display the songlengh correctly in further versions. This is essential because I was not able to use amaroK when giving a house party. Some songs stop after a couple of seconds due to having wrong song length information.
*** Bug 128861 has been marked as a duplicate of this bug. ***
Meanwhile amaroK appears in version 1.4.1 and I am still disappointed that amarok displays the length of many songs incorrectly. :-( To be more precisely as in my previous comment I am adding the following lines below: I am using the XINE engine to play music files. MP3 files as well as OGG files are victims of this bug. Other distributions seems to have the same problem (I am using Fedora Core 5 and Kubuntu 6.06 LTS on different computers). Having a look on my playlist the song length looks more like a random generated value. Affected songs have either no length or a random length. Sometimes it is not possible to move the scrollbar in order to jump forward in the song. Most of these songs are no more than 5MB large and have a bitrate of 128KBit or 192 KBit Please do not forget comment 1. These information are still valid!
1. Could this be a dub of Bug 107614? 2. I also have this problem. It exists with the xine engine and the helix engine. I am using Amarok 1.4.1. The described workaround in bug 107614 does not help. In talk radio shows the last seconds can be crucial. This bug is a show stopper for postcasts with Amarok!
Same problem here. I am using xine-engine. * Amarok (and Konq) shows the length as 16:xx * mp3fixer.rb shows length as 20:xx (amarok shows the same length even after mp3fixer writer the correct length in the xing header) * gxineclient shows the length as 43:xx * playing the file continues till about 47:xx Since I am using xine engine, this might be useful. gxineclient shows the file info as 22 KHz, 23 KB/sec MP3 VBR How does amarok/kde find out the length (I thought it was either taglib or xine-engine) ? Is there more than one place where this info is present ? What surprises me is that everybody is wrong and _different_.
I did some investigation and found the following "useful" info. taglib svn contains some fixes http://websvn.kde.org/trunk/kdesupport/taglib/mpeg/mpegheader.cpp?rev=515068&r1=288617&r2=515068 http://websvn.kde.org/trunk/kdesupport/taglib/mpeg/mpegheader.cpp?rev=579077&r1=515068&r2=579077 which fixes incorrect length calculation of VBR files. Unfortunately there isnt a newer release of taglib, so I had to build using SVN (which isnt too bad since taglib has no dependency). Also I added to that the fix given here http://bugs.kde.org/show_bug.cgi?id=130625#c2 And now amarok (and konqueror as well) reports the correct length. PS: The sad thing now is that xine-lib still miscalculates the length of the files. So even though it plays the file ok but seeking beyond what it thinks it the correct length stops the playback :(. I guess that should be a separate bug: since playback is handled by xine and song-length by taglib it might occur that seeking can stop playing of the song.
To #6: could you please check if current xine still has this problem and report it against xine?
I might have lost the copy of the bad file (I fixed most of my files using vbrfix). I thought I kept a copy for future debugging. With that copy, gxine is working ok. It could have also been fixed due to any xine upgrades I did in the last two months. Currently I have libxine-1.1.2.
I put many efforts into fixing tis bug. It was found out that taglib provides insufficient support for VBR encoded MP3 files. I have modified taglib. It should now be possible to get the correct song length. Bear in mind that the length of those files are estimated from a technical point of view to maintain performance. Therefore it might be possible that taglib independent player show a slightly different play time. My modified version can be accessed by: http://www.rafreider.de/taglib-1.4-vbr-hack.tar.gz
Created attachment 19569 [details] A modified version of taglib 1.4 The version is binary compatible. You DO NOT need to reinstall parts of KDE, Amarok or any other taglib dependent player!
@ Tobias Rafreider: Even with your patch the following mp3-file gets wrong length-information by taglib (27:00 min instead of 27:25 min according to Audacity). When I play it with Amarok the slider stops at 27:00 min but the file is played to the end. Here is the file: http://ondemand-mp3.dradio.de/podcast/2006/12/31/dlf_200612310931.mp3 It is part of the following podcast-service: http://www.dradio.de/rss/podcast/sendungen/essayunddiskurs/
Reply to #11: I checked with my patch mentioned in #6 (http://bugs.kde.org/show_bug.cgi?id=130625#c2), it reports 27:51 and stops exactly at that in amarok.
As I have already mentioned in comment 9, it is better and faster to estimate VBR files rather than interpreting each frame. Most other player use similar techniques. It has turned out that going through all frames slows down you system significantly. Updating your music collection in Amarok will take over 10 times longer. Or imagine you drag and drop a massive music folder to Amarok's play list. I have to consider those issue. If you only add one song to a playlist you will not notice any performance loss. For all who wants to have a more accurate song length I would recommend the following: *change line 245 in mpegproperties.cpp to: long nextPos = last; *change line 251 in mpegproperties.cpp to: while((nextPos=d->file->previousFrameOffset(nextPos)) != -1) Now taglib goes through each frame and calculates the average Bitrate to be able to calculate the song length out of it.
#13 solves the problem reported in #11. Thank's a lot!!! Do I understand it right that taglib gets only slower now while dealing with VBR encoded MP3 files without XING headers? If this would be the case I wonder if the chances in #13 should become the standard since folders full of VBR encoded MP3 files without XING Headers doesn't seem to be common (apart from people using streamripper). Or - in case this is possible - maybe a good solution were, if taglib would only work like in #11 while working with streams.
The patch mentioned in #12 _also_ fixes the problem without going through all the frames and just looking at the xing header. So, maybe the file contains a valid xing header which the patch in #11 is not able to properly parse. Just a possibility!
Unfortunately I found a lot of other files which lengths are even wrongly detected by taglib-vbr-hack with the modifications in #13. They are all part of the following podcast-service: http://www.ndr.de/podcastlink/ndrinfo_radiokirche_wasglaubensie.xml Here are some example-files: http://213.200.64.229/ndr/mp3/podcast/ndrinfo_radiokirche_wasglaubensie/20060701_ndrinfo_wasglaubensie.mp3 http://213.200.64.229/ndr/mp3/podcast/ndrinfo_radiokirche_wasglaubensie/20060728_ndrinfo_wasglaubensie.mp3 http://213.200.64.229/ndr/mp3/podcast/ndrinfo_radiokirche_wasglaubensie/20060805_ndrinfo_wasglaubensie.mp3 http://213.200.64.229/ndr/mp3/podcast/ndrinfo_radiokirche_wasglaubensie/20060902_ndrinfo_wasglaubensie.mp3 http://213.200.64.229/ndr/mp3/podcast/ndrinfo_radiokirche_wasglaubensie/20060923_ndrinfo_wasglaubensie.mp3 Amarok plalys them to the end but the length slider stops to early.
Tobias Niwi, what are the correct duration for the podcasts ? My amarok is stopping _exactly_ when the slider stops. These are the durations, 01.07 - 4:01 29.07 - 3:59 05.08 - 4:00 02.09 - 3:55 23.09 - 4:00
I tried it again with taglib 1.4 patched and unpatched: http://213.200.64.229/ndr/mp3/podcast/ndrinfo_radiokirche_wasglaubensie/20060701_ndrinfo_wasglaubensie.mp3 Date: 01. July 2007 Audacity: 4:01 min. Taglib 1.4: 3:55 min. Taglib 1.4-vbr-hack + #13: 3:55 min. @ Debajyoti Bera: Do you use taglib 1.4 + #12 or unpatched?
@Tobias Niwi: I use taglib 1.4+#12
To comment 11: Of course taglib is slower now, but most users won't notice. If a VBR file has a XING header, the song length is calculated upon that. The problem are files without XING header. They can be CBR or VBR. CBR files must be treated as VBR without XING headers to ensure a sensitive song length. My original hack in comment 10 uses 100 frames for that. Sometimes my hack ignores XING header information. Most MP3 files are between 2:30min and 5:00min long. I had a bunch of MP3s having dubious XING headers. If a VBR with XING undercut 2:30 or exceeds 5:00 the hack goes through 100 frames again and estimate the length. You will have noticed that VBR files might have strange average bitrates. I give you an example. Image 10 frames have the following Bitrates: 128, 128,128,128, 192, 160, 96, 128,192,128 The average bitrate is: 141 (this is implemented in my hack) 141 is not a valid bitrate in MPEG standard. Programms like XMMX and mp3info calcaulate the statistical mode instead which is the number occurs most. Thus, XMMS would give us 128 as bitrate. I try to provide another hack using the algorithm like XMMS in about 2 weeks. Last but not least. If you use Audacity to find out the song length you get always an accuarte song length. Audacity is music editor and goes always through all frames to illustrate you the frames on screen. I am sure if you compare some songs XMMS you will detect some small deviations.
*** Bug 129384 has been marked as a duplicate of this bug. ***
Is this an Amarok bug or a taglib bug then?
taglib's, it seems.
It is a taglib problem!
Just to clarify some of the things here -- this isn't as clear cut as it would seem. I've actually got some code around that does a pretty good job of guessing if a file is CBR or VBR, but just going through all of the frames in every file really wouldn't be an option. I'm pretty sure that that's what i.e. iTunes does and as such it takes several hours to import my collection that JuK can do in 5 minutes. (About 50 GB on a network share.)
It totally agree with Scott to go not though all frames. It slows down the system significantly. That's why my hack only considers 100 frames in the middle.
Scott, I agree that calculating the length of a song without proper header is quite tricky, but I think the request of this bug is quite limited. The mp3 header parsing code is buggy in taglib. Several of the early comments and patches are merely trying to address that. E.g. XMMS does not scan the whole file and I have checked the lame mp3 header code (and another unofficial mp3 header spec) - its different than whats in taglib. I made a reasonable attempt to fix the lookup tables and the algorithm in https://bugs.kde.org/attachment.cgi?id=18092&action=view Of course if your awesomeness fixes the general problem of determining the correct length of any file that makes me more than happy :-).
It seems that this got mixed up a bit before reassigning to TagLib. The original report is for Ogg, which is distinct (code-wise) from the issues with VBR MP3s. (Which is covered in another report.) Could the original reporter please send a problematic file to wheeler@kde.org with the name 128388.ogg?
Unless I accidentally deleted it, I never got a broken ogg for this report and still can't reproduce it. If you have such a file around, please send it per the instructions in my last comment.