Last week, Michael Matz contributed some code
to the audiocd:/ IO slave in KDE CVS to make ripping audio CDs child's play. When you browse an audio CD with this new code (using, for example, 'audiocd:/' in Konqueror), you will find two subdirectories: MP3 and Ogg Vorbis. Each subdirectory will list
all the tracks on the audio CD with the appropriate extension (.mp3 and .ogg).
Each track can then be dragged to any KDE drop location and be converted automatically into the MP3 or OGG compressed formats. In addition, if the track has a CDDB entry, the file is automatically named for you and the .MP3/.OGG tags are set appropriately. The obligatory screenies are linked in the text above. Expect rollout for KDE 2.2, currently scheduled for beta release on April 2. How's that for simplicity? A more complete explanation from Michael is available below.
Michael Matz explains how audioCD ripping works:
Audiocd:/ creates a virtual view (or better multiple views) of the content
of audio CDs. These multiple views are collected in virtual directories
which all (besides one exception) are subdirectories of the root directory.
The actual set of views available to the user depends on how kio_audiocd
was compiled, and if a network connection was possible (for the CDDB request).
Most of these views consist of one file for each audio track. The difference inthe views is only the actual name of these files, and the content, when
those (up to then virtual) files are read:
- There is one view listing the tracks by number in "By Track/"; the
files are named "Track XX.wav" with XX being a number. When read they
are normal .wav files. - One view lists the track by track-name; in "By Name/". The files are
called "XX .wav", where 'name' is the track title as it comes
from CDDB. The content of these files are identical to those from (1),
just the name is different. This view only exists if a network
connection exists for CDDB lookups. - Another view has the same content as (2) (same name and content of the
.wav files) but is located in the directory "", where ToD is the
Title of the Disc coming from CDDB. If there was no CDDB query this
view nevertheless exists, in which case the title is "No Title" and the
track names are "Track XX.wav" (so the content is identical to (1)). - If libmp3lame was available when compiling kio_audiocd, there is a view
in the directory "MP3/"
(screenshot).
The names of the files there are the same as
used by (3), except the extension is ".mp3" instead of ".wav". When
read, those files are normal mp3 files (they are coded on the fly,
while ripping the track/reading the file). - If libvorbis was available when compiling kio_audiocd, there is a view
in the directory "Ogg Vorbis/"
(screenshot).
The names are the same as in (3), except now the extension is ".ogg".
When read those files are Vorbis Ogg files (created the same way as (4). - The root directory itself has a view. The files are in the form
"trackXX.cda"
(screenshot),
which contain the raw headerless data of
this track (the exact same info as the .wav files, without the 44 Bytes
header). - The are two other directories which should be ignored for now:
"Information" and "dev").
It might be good to know, that some of the strings above are i18n()'d
(internationalized). These include the "Track XX", "By Name", "By Track",
"No Title" and "Information" strings. The files in the "MP3", "Ogg Vorbis" and
"dev" directories and the "trackXX.cda" files are not i18n()'d.
As should now be clear, the existance of certain directories depends on
compile time environment and runtime environment and is not changeable by
the user (except the CDDB information depends on a network connection).
The files in most subdirectories are virtual, because they don't exist,
similar to e.g. the pop3 slave which also looks as if it provides "files"
although these are messages on some mail-server. But the virtuality makes
no difference, as no user of audiocd:/ could tell if this or that
particular URL now is a file, or not, which of course is true for all
URLs, not only the audiocd:/ ones).
When a URL from one of the "MP3" or "Ogg Vorbis" directories is dropped,
its content is copied to the destination. For (1)-(3) this results in
.WAV files, for (4) and (5) in some compressed audio files (corresponding
to .MP3 and .OGG, respectively), which additionally have encoded the
CD-title, author and trackname if CDDB was available at the time (those file
formats provide a means to encode such auxilliary information).
Comments
This is sooooo cool :)
I've been using this for some time now (since the day the commited it to the cvs), and it works like a charm! Ripping audiocds have NEVER been easier...
KEEP IT COMING!!!............
I should add, that the code for wiring mp3 and
ogg encoding to the grabbing was developed by
Carsten Duvenhorst.
The hits just keep on coming!! Glad i'm not one of the xiamian investers. Thats what happens when you believe to much press and to much slashdork hype.
Craig
Theres stuff just like this in GNOME allready.
I went to gnome.org and freshmeat and found at least 13 apps that do the same thing written for GNOME. They just aren't integrated into a browser, which is probably a good thing, protozilla lets you do that though.
Theres an MP3-OggVorbis DB and player integrated into natilus. Theres almost too many GNOME mp3 DB's for GNOME(like 20), it's good to see that KDE is cathing up on the software side of the desktops though, it's allready superior as a desktop, there's just not as much good software for it as there is for GNOME.
Huh? What good software Nautilus and redcarpet. Is there anything else? Gnome office? Is there such a thing? Please please don't say open office its not a gnome app. look at there app page compared to apps.kde.com. It even looks like crap. The apps are all amateur trash. What major project thats not corporate is going on there? Its all corporate in gnome land. Nothing grass roots is going on there anymore.
Craig
I use nothing but KDE as a windows manager and I prefer Qt/DKE apps, but I find myself using about 60% Gtk/GNOME apps, 20% motif apps 10% Qt/KDE apps and 10% something else(actually I use about 75% of my time in vi/ksh). Maybe it's just me but most of the stuff I need is not written in Qt or KDE, though I wish it was, I realy prefer KDE and yea I think that they need to catch up on apps, but the thing is that the KDE people are catching up. Hopefuly in a year Gtk and Qt will switch places on my comparison above and it's looking like they will.
What apps? I hav't seen any real good gnome apps. Grip and gimp are not gnome apps. What else is there? Am I missing something? I'm not counting Nautalus and redcarpet because they were developed by people with corporate interests. If you enclude those you have to through in the Kompanies apps and then of course kde wins by a landslide.
Craig
I use Gnumeric, gvim, gimp(though it's a gtk app), GNUcash, GBurn Xchat and a few apps that aren't GPL for work, like DB front-end stuff(too small to buy a Qt liscence, and some we bought). I realy don't want to get in some sort flame war, but I use mostly Gtk/GNOME apps. I realy think that KDE is a better desktop and it's what I use for a window manager, I also use a ton of windows apps not because windows is better it just has that stuff I need(im using IE right now). If there is a KDE replacement to any of the apps that is just a functional please show me I'd much rather use it. And again I'm not tring to start a flame war.
Man I'm sure you'd feel stupid if you went to freshmeat and saw that there's over 3 pages of GNOME mp3 rippers. For future refrence you look like an idiot if you post stuff that is just wrong, people can't ever take you seriously now. You can hope that people took your post as a troll except on dot.kde.org that's not realy a troll post, so I guess they either take your word or know that your an idiot.
Hey there friend i know theres gnome mp3 rippers. Thats not the point. I use grip all the time even though its not really gnome just gtk. I'm excited at the rate of kde advantacement compared to gnome. The kde developers are really kicking butt.
Craig
Your an idiot. Read my post before run your cake hole.
This is a great feature.
However, I have one question to ask: I'm not sure how the kioslave stuff works - but I would expect it's pretty modular and plugin like.
In this case would it be possible to distribute updates of this kind as small files (rpm or tar.gz whatever) so we don't have to wait for an entire update of KDE to get it and test it? I'd like to add this functionality to my KDE now without going to CVS.
> However, I have one question to ask: I'm not
> sure how the kioslave stuff works - but I
> would expect it's pretty modular and plugin
> like.
Rest assured that the kioslave stuff is very modular ; so much so that you can create your own and distribute it as you would a standalone app. Even the ones that come with kdelibs and kdebase by default can be ripped out, packaged by themseleves and distributed. They were not packaged by themselves because some of them are sort of more essential than others. For example, the three ioslaves that come with kdelibs: the file, ftp and http io-slave are important to doing anything on the desktop.
Regards,
Dawit A.
Hey, that's pretty slick!
I'm not a KDE user, but I've got to say 'Way to go KDE team'. That's a real nice feature.
Are you allowed to have spaces in the URL? Shouldn't that be audiocd:/Ogg%20Vorbis ? I dunno if it causes problems, but it probably does look nicer as it is.
Otherwise, rock on!
This is very cool. One question, will this take an MP3 and write it back to wav format, so it can be burned to an audio CD? If not, I'd like to add this to a wish list of features.
Yes, I want that too.
Integrated CD-Burner software in Konquerer would be so great....
um, excuse me, but holy ****! This is too awesome.
One thing though, I wanna know how it's supposed to get the album/song names too, now that someone bought and commercialized CDDB and KDE isn't allowed to use it anymore.
and I wanna know how they mixed the marble and beos themes in that audiocd screenshot :o)
What I wouldn't give to be able to use kioslaves from the console!
http://www.freedb.org/
nuff said :)
>What I wouldn't give to be able to use kioslaves from the console!
I agree, why should these be limited to the desktop. How hard would it be to let console programs use kioslaves.
Wouldn't it be great if I could issue the command:
cp http://www.kde.org/somepic.png floppy://pics
Maybe kioslaves belong outside kde?
try:
kfmclient copy http://www.kde.org/somepic.png floppy://pics
>What I wouldn't give to be able to use kioslaves from the console!
I agree, why should these be limited to the desktop. How hard would it be to let console programs use kioslaves.
Wouldn't it be great if I could issue the command:
cp http://www.kde.org/somepic.png floppy://pics
Maybe kioslaves belong outside kde?
kfmclient copy http://www.kde.org/somepic.png floppy://pics
You could write a shell script to wrap "kfmclient copy" and make it behave like regular copy, if you really want it.
Looks great!
This leads me to a UI issue: Could we get some "virtual directory" icons in there? It would be good to convey to the user that the icons don't represent actual data yet but instead a process that will create that data.
The usual paradigm is one where you select the verb first (open the tool you are going to use to do your work) and then the noun (select the files to work on). An verb-noun order example would be opening a word processor then opening a file to edit. An example of noun-verb order is the microsoft "open with..." right click popup menu. Noun-verb seems more natural. Does anyone have a link to some good methods of representing this on the desktop?
KDE is taking steps toward a unique UI experience that I think will differentiate it. Perhaps we could add something that will indicate the verb a little better.
Anyways, congradulations on helping KDE move beyond the current paradigms. :)
-pos
Just like links that are represented with a small arrow, to-be-computed-datas could be represented with a small gears (like kde one)
Cool. But now, can I do the reverse? For example, insert a disc of MP3's, and reconstitute them as WAV files on the hard drive -- complete with a total time/size listing in the target?
This would make it quite easy to create audio discs for the car from MP3 collections...
Try eroaster for burning Audio CDs directly from your MP3 Files. Last week, the program gets Ogg-Vorbis Support too.
Pretty cool! I didn't know that the audiocd:/ interface was present in 2.1. I've gotten a little impatient and really don't want to toy with CVS so I tried to implement this using MIME types and have had partial success so far. Maybe someone can help me out, here's what I did:
In Konqueror select Go->Applications
In the Applications directory right click and Create New->Link To Application and name it Ogg Vorbis Encode.desktop.
Under the Execute tab in the Command box enter
oggenc -o /home/john/mm/mp3/%f.ogg %f
and select Run in terminal.
Under the Application tab highlight audio/x-wav and click the << button. Click OK.
Now, when you right click on a .wav file you'll see Ogg Vorbis Encode as an "Open with" option.
Here's the problem, when KDE executes the above command it's not replacing the %f with the name of the file you're trying to encode and the encoded file ends up being named ".ogg"
Can anyone point out what I've missed here? It seems like %f worked in KDE 1.0, but it's not working here.
Thanks
Well, you know, the BeOS already does something like this; in other words, it does the ripping but not the automatic encoding.
Cool to get it on GNU, though!
(I haven't test audiocd:/ system yet)
This looks very cool for audio cds, but what about mixed-mode and data-cds?
is it bad idea to add in future example cdfs:/ -file system to konqueror
which opens a tracks for anykind of cdroms just like cdfs-filesystem patch?
( http://www.elis.rug.ac.be/~ronsse/cdfs/ )
It just makes possible to make iso-images and audio-tracks
ripping (and maybe cdrdao images)for drag and drop style.
I have a few questions:
What about the bitrate? Is it fix? Can I change it?
Can I edit the CDDB/ID3TAG info myself as well?
And one more question: I think you said it uses paranoia library for ripping? I know that there might be difference in quality of ripping the same song when doing this more times. Esp. when the disc is scratched, dirty, etc, it can be ripped badly (with more or less successfully corrected errors). Will then KDE tell me about such problems?
Thank you,
Wanthalf
First of all I want to thank you for contributing to the kde project, but I have a few remarks.
I seems to me that not al the functionality should be implemented in the IO slave.
It is a good idea to have different views concerning renaming of "TrackXX.cda" to " - ", but the views concerning the virtual .wav, .mp3, .ogg files are out of place.
The proposed (and implemented) method provides (an interface to) the functionality of converting .cda files to .wav/.mp3/.ogg formats. BUT this functionality is only provided when you're copying from a CD (audiocd:/).
A different interface has to be implemented to provide he same functionality when copying/converting .cda/.wav files from a normal directory (file:/). This is the tell tale sign of functionaly implemented in the wrong place.
When a file is moved you get a little popup menu that lets you choose between 'copy here', 'move here' and 'link here'. This popup menu could be extended in such a way that conversions can be done on the fly AND from any kind of url.
So when one drags a .cda file the popup menu should give a choose to 'copy here', 'move here', 'link here', 'convert to wav here', 'convert to mp3 here' and 'convert to ogg here'. Similar options could be provided for the .wav, .mp3 and .ogg file formats.
The right click popup menu should provide similar options.
I hope you find my comments usefull, if you have any questions, just e-mail me or reply, I'll be happy to clarify my comments.
Johan Veenstra.
I agree with you. The ioslave as it is, is a nice idea and is very useful. It makes me use only one sofware ! (like the ftp ioslave). So it is very great. The need for virtual files and a folder with the title of the album is clear to me, not only in this specific context.
But the conversion function is confusing and mixes concepts,as you mentionned it. I probably canno't compress .wav files to .mp3 if I have them on my disk even if the code has for sure been implemented in the audiocd-ioslave.
I think the idea of extending the functionnality of copy/move/link to copy/move/link/convert could be usefull, not only for ripping or converting music but for any kind of files conversions or for backups.
But if you want to convert a file, you don't always want to move it. So an other convert-icon on a toolbar too would be great too (as the filter-icon is).
Cheers to all kde people here :-)
This would be a great enhancement indeed although the audiocd-kioslave as it is now is a great thing, too.
The most flexible way would be to register additonal drop-menu items for certain file types "on the fly" that is, an "extension" can add such a menu item if it's loaded or if KDE is started. ("Uncompress to directory Archive.tar.gz" if dropping a tarball?)
Sounds like a great idea! However I doubt that this will make it into KDE 2.2... :-( )
Greetinx,
Gunter Ohrner
I think that this is great.
Will this be able to send info to CDDB, like grip.
Also will it fill out ID3 info for mp3s, and the same for oggs.
Can you name the files before you rip them.
I think that this should be possible to do to any wav file on your harddrive.
Maybe something like this. When you right click on a wav file, it has an option for extend veiw, an extra panel will open in konquerer where these options are aviable.
This is so exciting!
Just one question, a little off topic ...
We are getting so many new tags for konqueror -- smb:/, audiocd:/, floppy:/, etc.
Does anyone know what the entire list is? Is it posted somewhere?
Jon
I don't know of a list of all ioslaves ever written, but you can find a list of those that are installed on your computer by going to the control panel, choosing the item about information, and then clicking on the "ioslaves" one.
check this
http://www.andamooka.org/reader.pl?anid=kde20develkde20Bkioslavebase_h&c...
Not mentioned:
You will need the latest libmp3lame ( > lame 3.88a) from the CVS to be able to encode to MP3.
lame 3.87 will NOT work.
lame is available at www.mp3dev.org;
Lame CVS Tarballs at http://cvs.sourceforge.net/cvstarballs/lame-cvsroot.tar.gz
I can't wait for the next release (2.2) with this GREAT, AMAZING, WONDERFULL, fetaure. Great work!
I can't wait for the next release (2.2) with this GREAT, AMAZING, feature. Great work!
wouldn't it be a lot easier if there would be an option somehow on selecting a kioslave to use, because the amount is growing rapidly. (e.g. I even read that someone is developing a diamond rio kioslave.) . maybe you could have an option just like network and root etc, named kioslaves or something, and there list them so everybody knows what is available.
When compiling KDE2.2, I have trouble linking the audiocd files.
The various MP3 libraries do not contain functions like:
lame_set_VBR
I have these versions available, and I don't see the functions:
lame-3.13 lame-3.89 lame3.50 lame3.70 lame3.87
So, which lame is the code to be compiled against? I know that
you prefer Ogg Vorbis, but portable Ogg Vorbis players are
rather rare.
Its kool. ond quetchion tho, when u rip files from a cd, does it reck the original copy?
KMenu->Settings->Control Center->Sound and Multimedia->Audio CDs