Version: (using KDE KDE 3.5.0) Installed from: SuSE RPMs OS: Linux Just installed KDE 3.5 RC1 on Suse 10.0 OSS on Via Epia 10000M. BenQ DVD R/W, works fine. When trying to rip an audio CD, the process is very slow (about less than 100 B/s). Tried several CD's, same result. Ripping and encoding with K3b or Kaudiocreator works fine.
Does it happen to all CD's or just one? Is Error correction turned on? If you turn off error correction does it speed up?
Hello, On 17 Dec 2005 21:42:14 -0000, Benjamin Meyer <ben@meyerhome.net> wrote: > > > ------- Additional Comments From ben meyerhome net 2005-12-17 22:42 > ------- > Does it happen to all CD's or just one? Is Error correction turned > on? If you turn off error correction does it speed up? > It happens to all CD's, also CD's which are succesfully ripped with K3b. Error correction was turned on, but turning it off didn't make any difference. walter Hello,<br><br><div><span class="gmail_quote">On 17 Dec 2005 21:42:14 -0000, <b class="gmail_sendername">Benjamin Meyer</b> <<a href="mailto:ben@meyerhome.net">ben@meyerhome.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <br>------- Additional Comments From ben meyerhome net 2005-12-17 22:42 -------<br>Does it happen to all CD's or just one? Is Error correction turned on? If you turn off error correction does it speed up?<br></blockquote></div>It happens to all CD's, also CD's which are succesfully ripped with K3b. Error correction was turned on, but turning it off didn't make any difference.<br> <br> walter<br>
Can you try several different encoders. Do you find it slow when you rip a cda or wav?
cda gives higher speed (about 500 kb/s). FLAC is fast, >1 Mb/s. Wav is quite slow: about 200 kb/s, but still way faster than ogg en mp3.
I find that when ripping CDs to ogg (didn't test anything else) the timings are *much* worse compared with cdparanoia and parallel oggenc. CPU usage is smaller when I'm doing direct encoding via KDE. I'd suggest putting a *big* buffer between the CD-reader and the encoder; I believe that the encoder and the CD-reader wait for each other, so that the CD and the CPU idle sometimes. In another project I simply created a socketpair instead of a pipe, set the maximum socket buffer to 256M (and the buffer for one of the pair), and off it went ... I know that this is not applicable here, but something similar would bring a speedup, I believe. Regards, Phil
same problems here. tested ripping wav, mp3 and ogg, 1 song each. Medium quality settings. wav is fine, elapsed time 56s, file size 53MB. (btw. encoding with lame or oggenc takes about 30-40s). mp3 takes very long (4min), progress dialog says "... of 145.1MB complete" At end of conversion, progress bar shows 3% instead of 100. ogg shows a conversion speed of 200-300B/s, resulting in 14 days, but fails after approx 2 minutes. created file is 32kB is size and useless. Tested with kernel 2.6.15.1, KDE 3.5.2 compiled from sources, Linux is a recent LFS.
I can also verify this issue. The slow mp3(lame) encoding is caused by calling the binary itself. Before KDE 3.5 the lame libary was used and since 3.5 the binary is called. This forces the lameplugin to wait for lame to write the chunk of data (1 sector 2352 bytes) to disk before reading the next chunk from cd and this slows down the whole process dramaticaly. from the lame plugin: // We can't return until the buffer has been written d->waitingForWrite = true; while(d->waitingForWrite && d->currentEncodeProcess->isRunning()){ kapp->processEvents(); usleep(1); } I think the only way to avoid this slowdown is to swith back to the lame library call or make a big buffer and split the reading/encoding process.
We can't switch back to the lame library because that has bugs in perticular if you encode with variable bitrate the filesize will not be written
Same here. Before 3.5 it was fast, now it is (for me) unusable slow. I'd say better with a bug (which I never saw) than so slow that it doesn't work for anybody.
*** This bug has been confirmed by popular vote. ***
This error still hapens on KDE 4.2.0 release. Kio ripping is much slower than k3b. I'm using Kubuntu Intrepid with kde 4.2.0 from ppa repositories
Is this bug actually still present in current lame releases ? (I never experienced any problem with it, I'm still running the audio-cd ioslave from 3.4 due to this) Alex
Yeap, the problem still occuring in the kde 4.2.0 release. With the K3b ogg, It take only 4 minutes. With the ioslave it take about 2/3 hours. Btw, I converted the generated ogg to mp3 with lame and the conversion takes only a few minutes.
(I'm also just a user here...) I mean, if there was a problem in the lame library a few years ago, maybe it has been fixed in the meantime ? So that the workaround is maybe not necessary anymore ? Alex
I think this isn't a lame issue itself, but the way ioslave uses it. Lame is pretty fast, but kio using lame is very slow. with kde 4.2.0 i'm using k3b to rip to ogg files and then converting to mp3 using a shell script. I'm using Kubuntu 8.10 with kde 4.2 packages from ppa.
Yes. Until KDE 3.4 the audio cd ioslave used the lame library. Since KDE 3.5 the audio cd ioslave uses the lame binary, which makes it that much slower. Apparently there was some problem with using the lame library (see one of the posts above). The questions is whether the current version of the lame library still has this problem. Alex
*** Bug 241611 has been marked as a duplicate of this bug. ***
*** Bug 192550 has been marked as a duplicate of this bug. ***
Audio CD ripping is still very slow. I just ripped all tracks of a disc to flac format with Dolphin, it took ~20 minutes to complete the task. K3b installed on the same system ripped the same tracks to flac in ~3 minutes. Operating System: Arch Linux KDE Plasma Version: 5.16.0 KDE Frameworks Version: 5.59.0 Qt Version: 5.12.3
This issue persists. Operating System: Arch Linux KDE Plasma Version: 5.20.0 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.1