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.
Ah, great to see some more exposure for what I have always thought to be the best KDE feature ever, or at least the best example of KIO's power.
Shame the article doesn't mention the KIO iPod slave:
(and also a shame that KIO slave doesn't do photos yet)
My apologies for not mentioning the iPod slave. However, I don't own an iPod and never really knew about this feature.
I can only write about things I know about and have learned how to do myself.
But, thanks for taking the time to read and for the suggestion. Perhaps in a future How-To.... now all I need is someone to send me an iPod to try it out on! ;o)
Ah, since you mentioned the iPod within the first ten words I figured you had one!
I see a lot of them.... just can't afford the expense. The kids needed shoes ;o)
Who needs shoes anyway? ;-)
Who needs an Ipod?
Perhaps someone that needs a good music player.
mp3 players are cheap
If I did buy a high storage media player, I'd most likely go with an iRiver. They play OGGs, which is what most of my music collection is now-a-days.
Or an IAudio
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?
I -think- so, but as I don't have an iPod/etc. either I don't know for sure. There is a 'media device' tab on amarok so it is quite likely true.
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.
This procedure is now documented as part of the official KDE User Guide.
Read here: http://docs.kde.org/en/3.4/kdebase/userguide/audio-cd.html
That's great! The more exposure of these wonderful KDE functions, the better.
Also feel free to submit a promo/dot article on new KDE stuff documented...
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.
I also get reading errors, on an athlon64 3400, 64bit gentoo. Don't know why :S
In 4.1 the ripping error messages will be surpressed as it isn't much to worry about. But for those of you who like them there will be an option to enable it :)
Try using kaudiocreator instead then.
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 :)
the BR is
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.
(if you didn't get it, I really do love this feat. :)
KAudioCreator uses kio_audiocd internally for ripping to WAV before it encodes it using one of the configured encoders.
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.
That's why I say that encoder should be chosen in the audiocd configuration.
Maybe lame is buggy or audiocd does not tell it to write that header or something like that.
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.
> The kioslave interface unfortunately can not seek
Yes, and this is a major shortcoming of KIO. Makes it quite unsuitable for multimedia uses.
> This probably means that the encoder does not write the XING header.
kcontrol-> "Sound & multimedia"-> "Audiocds"-> "MP3 Encoder"-> "Write Xing VBR tag"
Yup there is a bug open for the variable bit rate problem. Unfortunettly it isn't an easy fix so I don't think I will be able to fix it for 4.1
Is it a lame bug or a konqueror bug?
Why not do the same thing for DVD?
1)You put a DVD video
2)In Konqueror, you have several folder:
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.
Is not the idea good?
This would only be useful in places where deCSS (or libdvdread) is legal to use. It would likely be stripped out of most mainstream distributions.
legal stuff this should not hold back development
of great technologies!
Go konqi, go!
I've always wondered how the licensing for DVD playing software works. Would it be possible to buy KDE a license so they could distribute a feature like this?
only if we would make kde closed source and let every "user" pay a fee for it's usage. and more other ugly things.
Sounds reasonable... No? ;)
I find it amusing that you are so bold with other people's possible legal liability issues.
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.
Sure. It's simply not my decision to make, or yours, since it's not our liability.
Unless you are willing to be the one that writes and distributes such code, thus becoming the responsible party, it's still being brave with other people's risk.
Or for people with non-encrypted DVD collections
(Most B-Movies, like kung fu dvds or gore flicks are not region-encoded and not encrypted...)
Or just people's personal DVD's.
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?
that would probably provide a much better experience.
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 :-/
See what I mean about KDE's marketing.
This is getting pathetic and ridiculous. More than a month after the erlease of KDE 3.4, the promised Flash feature guide is nowhere to be found and the screenshot section shows dated 3.3 shots.
Way to go on selling this release to the Linux community!
>Way to go on selling this release to the Linux community!
"selling"? "pathetic"? What part of "free" and "volunteers" you don't get?
Apparently Al is missing the part where you volunteer yourself.
That always seems to be the case with the loud-mouths ;-)