Version: (using KDE Devel) Installed from: Compiled sources OS: Linux variable bitrate oggs are played about 30% too fast. This is both with the arts and xine engines. The problem is not very obvious as musically, the songs retain their coherence, and the pitch is conserved. Interestingly enough, juk has the same problem, but not noatun. This might be due to the fact the noatun uses mpeglib for the decoding whereas amarok and juk use akode... If needed I can send an ogg exhibiting this behaviour.
Program version missing. (Feel free to reopen)
What part of recent cvs (ie a few minutes ago) is unclear as far as versions go?
Where did you state you're using CVS?
What a bizarre bug. It is possibly aRts is using xine to play to ogg files, so it may be that something is wrong in xine-lib?
Can you update to current and try to see if this is still going on?
Le Mercredi, 2 Février 2005 06.10, Greg Meyer a écrit : > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > You are a voter for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=95385 > > > > > ------- Additional Comments From greg gkmweb com 2005-02-02 06:10 ------- > Can you update to current and try to see if this is still going on? I'm sorry, but yes... But not when mpeglib is used as the decoder (such as when using noatun), but then mpeglib was always well-behaved in that regard... Do you need me to attach a guilty pm3 ? -- Cyrille Dunant
I think this must be a bug in aKode or aRts, reassigning the KDEMultimedia seeing as there is no product category for either of those listed.
Why do you think this is a kdemultimedia arts or akode bug (note: they all do have product entries on bugs.kde.org!)? The reporter is wrong about his mpeglib and arts assumptions. Both juk and noatun use exactly the same code when playing files through arts, it's either mpeglib, aKode or arts-builtin ogg support (yes, there's three of them, don't ask me why). Furthermore he was talking about xine playback not working in amarok, why should this be a kdemultimedia bug either? As long as the buggy component has not been found I suggest keeping this with amarok instead of moving it into another random product.
> The reporter is wrong about his mpeglib and arts assumptions. Both juk and > noatun use exactly the same code when playing files through arts, it's > either mpeglib, aKode or arts-builtin ogg support (yes, there's three of > them, don't ask me why). Furthermore he was talking about xine playback not > working in amarok, why should this be a kdemultimedia bug either? OK, I'm the reporter, and unless I am half crazy, the sound is different when playing the _same_ mp3 with noatun or juk. The natural assumption is that they use different decoders. Since I _know_ (I tested that) that akode plays it wrong, _and_ xine plays it wrong _and_ mpeglib (I will say mpeglib, by elimination, but that is using noatun) plays it right, I assume there is - a bug in xine-lib - a bug in akode - the two outputs are identical to my ear, thus I tend to assume the bug might have the same nature. Of course, I don't _know_ that. > As long as the buggy component has not been found I suggest keeping this > with amarok instead of moving it into another random product. Anyways, thanks for taking time to look at this issue. -- Cyrille Dunant
> OK, I'm the reporter, and unless I am half crazy, the sound is different > when playing the _same_ mp3 with noatun or juk. The problem with that is, if you choose arts-playback in JuK you simply cannot use a different plugin. It will be the same arts-plugin used in noatun (both JuK and Noatun just tell artsd to play a file, the rest is up to artsd). That's the reason why I'm still not sure how you managed to get different sound-output in JuK and Noatun.
Le Vendredi, 4 Février 2005 11.50, Stefan Gehn a écrit : > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > You are a voter for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=95385 > > > > > ------- Additional Comments From mETz81 web de 2005-02-04 11:50 ------- > > > OK, I'm the reporter, and unless I am half crazy, the sound is different > > when playing the _same_ mp3 with noatun or juk. > > The problem with that is, if you choose arts-playback in JuK you simply > cannot use a different plugin. It will be the same arts-plugin used in > noatun (both JuK and Noatun just tell artsd to play a file, the rest is up > to artsd). That's the reason why I'm still not sure how you managed to get > different sound-output in JuK and Noatun. There is more than one plugin which can play oggs. How are they chosen? Me killing arts between listening in juk and noatun could have had an effect? I somehow assumed that noatun defaulted to mpeglib for historical reasons... -- Cyrille Dunant
Artsd just chooses the plugin with highest priority in its desktop file. So if you have more than one ogg-playing plugin installed it will always choose the opne with highest priority. Applications using artsd cannot decide which plugin is used for playback if they just create a PlayObject (this is what Noatun and JuK do) and use that one.
Can you test this either with 1.2.2 or current cvs and let us know if it still occurs?
Closing, as it seems nobody else reproduces this and we get no feedback from the reporter anymore. Please, test 1.2.3 and then reopen this if necessary.
I'm running 1.2.4 with gstreamer 0.8.10 and I'm seeing a similar problem with VBR mp3s. What I'm experiencing is changing speeds throughout the track - VBR goes up, play speed goes up, VBR goes down, play speed goes down. I'm also getting sound artifacts at various points during playback. I've tested the same mp3 file with XMMS and it plays fine.