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/"
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/"
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
which contain the raw headerless data of
this track (the exact same info as the .wav files, without the 44 Bytes
- 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).