Grr! This is a real bastard of a bug. What happens is that the audiocd: ioslave does not correctly finish writing Ogg Vorbis files. This results anywhere up to 2 seconds of lost audio at the end of the file (could be more than 2 seconds, but the ones I've seen have no more than two seconds missing). I'm perplexed that this bug has not been caught before now (at least it's not fixed in kdemultimedia-3.1.2 or 3.1.3). On the one hand, I think that I should re-rip my CD collection, but on the other hand, if I didn't notice it until now, how terrible could it be? Reproducible: Always Steps to Reproduce: 1. Enter "audiocd:/" into Konqueror. Rip some tracks (shorter ones are good for testing with, because they can be ripped quickly. Rip a track to Ogg Vorbis, and also rip it to WAV or MP3. 2. Compare the length of the Ogg with the length of the MP3 or WAV, or the length your CD player thinks the song is. You will probably find the Ogg is a second or two shorter than it should be. 3. Take the WAV you ripped, and use oggenc to create an Ogg file from it. Check the length of this file, and notice that it is consistent with the MP3 or WAV, indicating that the problem is specific to the audiocd slave, and not to the Vorbis or Paranoia libraries. Actual Results: I spent some hours tracking down the bug and writing a patch. The code in question is really not pretty. For an example of what pretty might look like, see an example which Google found for me: http://cvs.pld.org.pl/rip.hal/rip.hal/src/Attic/vorbis_handler.c?rev=1.1 Expected Results: The software should have realised it was doing the wrong thing and filed a bug report (including a patch) without user intervention. Then it should have re-ripped all my songs which it fucked up and made me a chocolate milkshake to compensate me for all those lost CPU cycles. If you can verify this bug/patch it should certainly be sent upstream.
Created attachment 17811 [details, diff] patch to fix bug 28887 This patch is against 3.1.3 but should work for earlier versions as well (at least 3.1.2).
Grrr! This patch is not the whole story . . . It seemed to fix my short sample track, bumping it from 0:14 to the necessary 0:16, but I still have one track which is 2:49 from audiocd/Ogg, but 2:52 from audiocd/WAV, audiocd/MP3 and oggenc. It is missing about 3 seconds of silence from the end of the track. :(
John, I've identified this to the KDE people and Dirk wants to know somere more information. Can you please open a KDE bug report at bugs.kde.org and set this information there? This looks to be a pretty major bug and I think they're pretty interested in finding out about this. Once you do, please post a link here to your bug. Thanks
Okay. The problem with my patch is that the code I've added does not get executed for all tracks. My guess is that on some tracks Paranoia gives an error when it tries to read the last sector, so the code leaves the while loop and never gets to my "if(currentSector==lastSector)" bit. What should really happen is that when the code gets to the "cleaning up" part, it should signify end-of-stream by calling vorbis_analysis_wrote(&d->vd,0), and then write out the remaining blocks of the Ogg. I can't yet see a "simple" patch for this . . . either I could do it with a goto, or I could duplicate a bunch of code, or I could pull some of the Ogg code out into a seperate function to avoid duplication. I just got your message about filing a bug report on kde.org . . . I will do this ASAP (need to shower first :)
I have added my comments to their bug http://bugs.kde.org/show_bug.cgi?id=60069 which was filed sometime in June.
Created attachment 17868 [details, diff] updated patch to fix bug 28887 Okay, here is a better patch, which will ensure that if audiocd creates an Ogg Vorbis file, that file will have a correct end of stream flag.
I still haven't heard from any KDE people about this. The man who originally reported this bug to the KDE bugzilla has tested my patch and it works for him. Has anyone else had a look at it? Any chance of getting it in before 3.1.4 is marked stable?
Something like this I would prefer to get done upstream. Perhaps you should email to the kde-devel mailing list to get someone's attention, and point out that this is a pretty serious problem. You can also email mueller@kde.org, as he was the one I origially contacted about this.
This patch has today been integrated into KDE CVS, so this bug should be fixed in anything >=kdemultimedia-3.2.0_beta2. Happy for you to close this bug now.
fixed in 3.2