Ripping tracks from a CD into OGG or MP3 is one of the most popular things we do with our home PCs these days. This How-To shows you how you can do this task quickly and easier than ever before, with the help of KDE and Konqueror. Read the complete article at Dave's Desktop - Ep. 21.

The new iAudio X5 seems to be the iPod Photo done right! (Support for ogg, USB Mass Storage-compliant syncing, movies, and USB Host photo syncing for the camera.) I'll buy one next week. Can Amarok (or any other playlist management app) auto-sync my favourites the same way as iTunes can?

It's not the best player around but it's proper bling bling and rather cheap starting at £69. Thinking of getting the new 60GB Photo model myself, although it's rather useless to get a Photo model until kio_ipod supports photos.

In my ripping experiences on three different systems, ripping directly to MP3/OGG does not work. It leads to lots of reading errors from the drive. I can only get perfect rips when I rip to uncompressed audio and compress it after ripping is finished... Maybe these systems are too slow to do ripping and encoding at the same time. All three systems are Athlon 800-1000 MHz.

This feature is so neat! A couple of days ago I bought a brand new Yepp portable player (which supports ogg!!), inserted it into an USB port, inserted an audio CD in the DVD drive, opened up two Konqui windows with 2 clicks on their respective icons in the kicker (thanks Media applet!), and d'n'd the "ogg" folder from the CD to the portable player. 30 mins later, it was done. Everything tagged well, everything ordered well!

The only problem with the audiocd:/ slave is that is missing the possibility to configure the album folder name for ogg/mp3/flac subfolder. There was an opened bug on BKO but is marked as closed while it isn't. I added a comment to it cause I was looking for the same exact options and I didn't dare to open a new BR but no one replied...let's hope that with some noise here I will get attention :)

As with all tools there are cases when the audiocd:/ slave are not the best tool for the job. It really shines if you want to do quick and simple pick and choose of songs from CD's or as you described d'n'd to USB devices. But if you want to rip one or more whole CD's the audiocd:/ slave has it's weakness, mostly in case of speed. For those big jobs KAudioCreator are a better suited tool.

Well, but id doesn't cost anything add support to virtual folders simply modifing the pathname as I described I tried to do in the BR.
And anyway if the KIO method has some flaws, I think the best solution would be fix them, not create (or encourage) alternative KDE solutions, cause with the audiocd:/ KDE is miles ahead all others competitors, usability wise.

I like the idea. The first time I saw this I thought it was the way it has to be done. Is like all people want it. If you want to copy the songs of a cd, then copy and paste it in the explorer window.
But in my personal use I've found it's very slow (in general, kio_slaves are slow) compared to other windows 'comercial' solutions. I think is lame related but I've seen how slow the kamera kioslave is so maybe it's konqueror's fault.
Also, when using varianble bitrates with mp3 I get wrong times. For example, a song of 3 min is recognized by amarok and other players (even in windows) like a song of 23 min. Another time, maybe lame related. Maybe it woulb be great to have the option of choosing the mp3 encoder in the configuration.

> Also, when using varianble bitrates with mp3 I get wrong times. For example,
> a song of 3 min is recognized by amarok and other players (even in windows)
> like a song of 23 min. Another time, maybe lame related. Maybe it woulb be
> great to have the option of choosing the mp3 encoder in the configuration.

This probably means that the encoder does not write the XING header. This header contains the tracklength, and is crucial for precise length determination with VBR-encoded mp3.

The kioslave interface unfortunately can not seek, so there is no way to go back and write a precise header later. This means the encoded files are really only suitable for streaming and not for storing.

1)You put a DVD video
2)In Konqueror, you have several folder:
- DVD5
- DVD9
- Divx/Xvid
- ...
3)drag and drop the divx, the DVD is encoded and you obtain a .avi file
or 4) drag and drop the DVD5, the MPEG2's DVD is re-encoded to fit to a DVD5 like the Windows software DvdShrink.

I appreciate observing what legal issues lie in wait for users around the world, but I also appreciate that not all users have the same limitations imposed on them (not every country observes software patents, for instance). Free software hackers should not buttress controlling multinational publishers by withholding copying programs like the poster described. Even the USA has the Betamax case which echoes the sentiment I'm trying to convey.

As a more constructive criticism, may I recommend making it super-easy to create Ogg Theora+Ogg Vorbis copies of movies ripped from DVD? I'm sure there are plenty of users with home movies they'd like to send to their free software-running family members. All the free software movie players support Ogg Theora+Ogg Vorbis movies, as far as I know.

Since there are perfectly legitimate uses for copying DVDs, it would be perfectly fine to give this functionality to everyone and (just like with audio CDs) let them choose to obey the law by not copying DVDs they don't have a license to copy.

We can trust that users know when to police themselves and observe copyright law.

Xine uses libdvdcss if it's available and it's perfectly legal.
Konqueror could make the same. If libdvdcss is installed then you can copy encrypted dvd, if you don't have it, then you can only rip unencrypted dvd.
That way, konqueror would not be illegal. It's the user that install libdvdcss that has the problem of decide.

recording seems to be very slow.
I have actually never seen it rip fast.
this gives me the idea that it is ripping the "anolog" way.
if this is so.. wouldn't it be possible to digitally rip the audiocd?

audiocd:/ uses cdparanoia which does it the digiatal way + it adds a *lot* of checking, since most cd-rom drives has buggy cdda hardware. It is those "paranoia checks" which leads to a good deal of re-reading. Technically you can set cdparanoia up to *never *ever* go for anything less then perfect, which in terms again will wear your drive out if you attempt to rip a badly scratched cd.... been there, done that :-/