Version: 1.1 (using 4.1.1 (KDE 4.1.1), volkerdi@slackware.com) Compiler: gcc OS: Linux (i686) release 2.6.24.7-smp I try audiocd protocol with a cdrom and mp3 folder. After copy and paste the generate file is unplayable(i heard only a strange noise,like an out of sync radio)
To fix this error in k3b the byte order has to be swapped and you have to check write wave header. It's the same problem with the audiocd_kio. Perhaps the lame command line parameters are wrong.
Reproduced on kubuntu intrepid with kde 4.1.3.
There is a big/little endian check in 'encoderlame.cpp'. To fix the static noise, command line option -x should added for little endian machines (Intel/AMD). There is a line #if __BYTE_ORDER == __LITTLE_ENDIAN in 'encoderlame.cpp'. Don't know why it doesn't work.
FYI, also fails on 64-bit (Kubuntu 8.10 using KDE 4.1.3)
I have same issue with the audicd kioslave producing only white noise. KDE 4.1.3 on OpenSUSE 11.1 RC1 on a x86 CPU. What would be good is to have the lame command line as a configuration parameter (or at least something that can be manually added to kcmaudiocd_encoder_lame_rc). While encoding I can see that the lame -x flag is used - I actually think this -x flag shouldn't be used by default. If calling lame from the command line without it it encodes just fine.
*me too*
I reported the problem in bug 171464, which is continued here. To answer the question about the current status: I am using lame 3.98.2 and kio 3.5.9 on Debian Lenny (testing). The problem is still reproducable. In addition I noticed that during copy/conversion process, two process bar windows appear with the same content. Im not sure if that matters. KDE is not able run the lame converter. Immediately after start it stops with no clear error message (the debug window shows no error or warning and the called command works fine on the command line).
*** Bug 171464 has been marked as a duplicate of this bug. ***
SVN commit 898479 by dfaure: Simply endianness check, but this was correct already (went into the "little endian" case here), so it's not the reason for the static noise in the generated mp3s. lame must have changed something about the need for -x then... CCBUG: 171065 M +8 -25 encoderlame.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=898479
SVN commit 898488 by dfaure: Make byte swapping configurable, until we find a way to figure out what the default value should really be. Use byte_swap=No in kcmaudiocdrc group [Lame] to disable byte swapping. CCBUG: 171065 M +9 -0 audiocd_lame_encoder.kcfg M +24 -6 encoderlame.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=898488
*** Bug 176024 has been marked as a duplicate of this bug. ***
The fix (work-around) doesn't seem to have made into 4.1.96 (RC1)?? I still get lame -x (which is wrong to begin with) and byte_swap does not have any influence on this (work-around fails). I kill any kio_audiocd process after testing to force reloading of the kcmaudiocdrc file, is that enough? I use kubuntu Jaunty amd64 packages for 4.1.96, updated a couple of days ago.
Found the solution: the setting is located in kcmaudiocd_encoder_lame_rc group [Lame]
*** Bug 181789 has been marked as a duplicate of this bug. ***
The bug is present in KDE 4.2. I'm running 64 bit Gentoo.
*** Bug 184355 has been marked as a duplicate of this bug. ***
This is the text from bug 184355 which has been marked a duplicate of this bug, hopefully it might help. Version: rev 925961 (using Devel) Compiler: g++ (Ubuntu 4.3.2-1ubuntu12) 4.3.2 OS: Linux Installed from: Compiled sources MP3 files generated by the audiocd kioslave are unlistenable as they sound like they have a very high background noise level with lots of white noise. The files are very loud compared to those generated by kaudiocreator. (Note that this sounds like a different problem to bug 171065 as you can hear the music at the beginning of the track but it degrades to total noise later on.) Debugging info: kio_audiocd(2882) kdemain: Starting 2882 kio_audiocd(2884) kdemain: Starting 2884 kio_audiocd(2882) AudioCD::AudioCDProtocol::initRequest: dir= "" file= "" req_track= -1 which_dir= 2 full CD?= false kio_audiocd(2884) AudioCD::AudioCDProtocol::initRequest: dir= "" file= "" req_track= -1 which_dir= 2 full CD?= false kio_audiocd(2882) AudioCD::AudioCDProtocol::initRequest: dir= "MP3" file= "" req_track= -1 which_dir= 4 full CD?= false kio_audiocd(2884) AudioCD::AudioCDProtocol::initRequest: dir= "MP3/" file= "Artist - 01 - Track 1.mp3" req_track= 0 which_dir= 0 full CD?= false kio_audiocd(2882) AudioCD::AudioCDProtocol::initRequest: dir= "MP3/" file= "Artist - 01 - Track 1.mp3" req_track= 0 which_dir= 0 full CD?= false kio_audiocd(2882) EncoderLame::receivedStderr: Lame stderr: Assuming raw pcm input file : Forcing byte-swapping LAME 3.98 64bits (http://www.mp3dev.org/) Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz Encoding <stdin> to /tmp/kde-devel-kde4/kde-kde-devel/kio_audiocdJH2882.mp3 Encoding as 44.1 kHz stereo MPEG-1 Layer III VBR(q=2) kio_audiocd(2882) EncoderLame::processExited: Lame Encoding process exited with: 0 kio_audiocd(2884) kdemain: Done kio_audiocd(2882) kdemain: Done Lame version: LAME 64bits version 3.98 (http://www.mp3dev.org/) Below is some info generated from the mp3gain utility for an MP3 (the same track) generated by the kioslave and one from kaudiocreator: kioslave (sounds bad): Recommended "Track" dB change: -11.870000 Recommended "Track" mp3 gain change: -8 Max PCM sample at current gain: 71388.495585 Max mp3 global gain field: 197 Min mp3 global gain field: 155 kaudiocreator (sounds good): Recommended "Track" dB change: -8.700000 Recommended "Track" mp3 gain change: -6 Max PCM sample at current gain: 35991.263142 Max mp3 global gain field: 193 Min mp3 global gain field: 135 (command used $ mp3gain -s s <file.mp3>) The "Max PCM sample at current gain" value for the kioslave generated file is very high compared to other mp3s in my collection which tend to be around 29-38k range (also generated in kaudiocreator) - e.g. twice the value. The "Min mp3 global gain field" is also a bit higher than for the other files but not by anywhere near the same proportion. I'm not sure if this is any help diagnosing the problem, or what additional details would be useful - if you need any more details let me know.
I can confirm this bug with KDE 4.2. Last version where mp3-ripping using audiocd kioslave worked for me was 3.5. I'm running 32-bit Arch Linux. Converting to wav, flac and ogg using the audiocd kioslave works without any problems. If I use command line `lame song.wav song.mp3` to convert any wav to mp3, conversion works as expected.
Confirming this bug in kde 4.2.2. Should be fixed.
Same problem here with 64bit 4.2.2 kubuntu and 64bi 4.3 beta 1 kubuntu
still present int kde 4.3 beta 2.. if that could be fixed for 4.3 it would be really great, because ripping mp3's is something my gf does quite often, and i always have to do it for her with grip..
Beat Wolf and other people who added a comment recently: until this is fixed, there is a simple workaround so you don't have to rip files for your girlfriend: just edit her ~/.kde[4]/share/config/kcmaudiocd_encoder_lame_rc and add [Lame] byte_swap=No
(In reply to comment #22) > Beat Wolf and other people who added a comment recently: until this is fixed, > there is a simple workaround so you don't have to rip files for your > girlfriend: just edit her ~/.kde[4]/share/config/kcmaudiocd_encoder_lame_rc and > add > > [Lame] > byte_swap=No I guess, by now it's confirmed that it's a byte order issue. Moreover, IIUC, the mp3 file format is LE since mp3s produced using lame with LE settings on an x86 box work happily with the Windows based players too. I don't have access to a BE machine to test the theory - maybe, I can try 'lame --bigendian ...' without '-x' and try to play the resulting mp3 on Winamp. I'll post about it after testing it. So, assuming that mp3 format is LE, why not just check for byte order and include '-x' param to lame only on BE machines? Then, the user doesn't need to dig through horde of documentation (which is this bug report) to enable the workaround.
I can confirm that the workaround works. I really really hope this gets into 4.3. Not only because right now that feature simply does not work for anybody, but also because from what ive read amarok 2.2 will use the audiocd kio to rip cds into the local collection, so this will create quite some bugreports if it does not work by then. great feature by the way :-)
(In reply to comment #23) > (In reply to comment #22) > > Beat Wolf and other people who added a comment recently: until this is fixed, > > there is a simple workaround so you don't have to rip files for your > > girlfriend: just edit her ~/.kde[4]/share/config/kcmaudiocd_encoder_lame_rc and > > add > > > > [Lame] > > byte_swap=No > > I guess, by now it's confirmed that it's a byte order issue. > Moreover, IIUC, the mp3 file format is LE since mp3s produced using lame with > LE settings on an x86 box work happily with the Windows based players too. > I don't have access to a BE machine to test the theory - maybe, I can try 'lame > --bigendian ...' without '-x' and try to play the resulting mp3 on Winamp. > I'll post about it after testing it. > > So, assuming that mp3 format is LE, why not just check for byte order and > include '-x' param to lame only on BE machines? > Then, the user doesn't need to dig through horde of documentation (which is > this bug report) to enable the workaround. OK.. Here is what I found: o. --big-endian is concerned with only input data and not the output produced (except for the decoding phase). As per lame manpage: --big-endian Instructs LAME that the samples from the input are in big-endian form. Required only for raw PCM input files and only available if LAME was compiled with libsndfile. For us, the input is RIFF WAV (without the RIFF header of 44 bytes) with PCM encoding - which is by definition LE. http://en.wikipedia.org/wiki/Resource_Interchange_File_Format In fact, that's how the data is stored on audio CDs: http://en.wikipedia.org/wiki/WAV#Audio_CDs o. On i386 linux box with LAME 3.97 and 3.98, the mp3s produced with -x are not playable with Winamp - which is what this bug is all about. Again, as per manpage of lame: -x Swap bytes in the input file or output file when using --decode. For sorting out little endian/big endian type problems. If your encodings sounds like static, try this first. Without using -x, LAME will treat input file as native endian. Which means that on i386 linux box, it's producing LE files without '-x'. So, I think it's safe to use the byte order test to decide when to include '-x'. :) Hope to see this fix get incorporated in the next release instead of relying on the workaround.
SVN commit 993656 by dfaure: Let's default to no byte-swapping when making mp3s with lame. The logic inside lame was changed in July 2007 according to lame's ChangeLog (or maybe it was one of the 2005 changes), so by now we can assume lame does the right thing (and still have the hidden config key if not). Fix will be in 4.3.0 BUG: 171065 M +1 -1 encoderlame.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=993656
(In reply to comment #26) > SVN commit 993656 by dfaure: > > Let's default to no byte-swapping when making mp3s with lame. The logic inside > lame was changed in > July 2007 according to lame's ChangeLog (or maybe it was one of the 2005 > changes), so by now we can > assume lame does the right thing (and still have the hidden config key if not). > Fix will be in 4.3.0 > BUG: 171065 > > > M +1 -1 encoderlame.cpp > > > WebSVN link: http://websvn.kde.org/?view=rev&revision=993656 Thanks David for the fix. :)