0

I would like to be able to rip a CD through the command line (using cdparanoia and lame, preferably) without having to use temporary files. I'm thinking that this would save some time with the encoding process, but if this isn't the case, please let me know.

So far, I've tried cdparanoia 1 - | lame -f --silent - track.mp3, and it worked well on that first track. However, I can't figure out how I can pipe all of the tracks from the CD in this way without doing some slightly messy parsing of the CD track table.

Is this kind of thing feasable in a one-liner, or will I have to grab the number of tracks and iterate?

EDIT: I'd appreciate input on whether or not ripping the full CD in this way and splitting tracks post-encoding would be any better or more feasable.

1 Answers1

1

Depends on filesystem caching. If the wav file is deleted right away, it may never be written to disk in the first place. In such a case there should not be a noticeable difference to piping directly. If you have enough free RAM you could always do it in a tmpfs/ramdisk and only copy the final result to the real filesystem.

Rather than piping it directly to an encoder, the program that does the ripping would have to start the encoder by itself. Encoders usually only take one file at a time, so a multi pipe is not feasible.

cdparanoia frontends such as abcde sometimes offer an option to save disk space, however the method used by abcde is actually much slower than ripping the CD to files first. I think part of the problem is that you don't know how fast you're ripping the audio data, and how long it takes for the encoder to actually process it. So if you pipe things, the drive may not be able to operate at optimal speeds.

The abcde manpage says:

Use only if your system is low on space and cannot encode as quickly as it can read.

So unless the method used by this script is bad, there should be no speed penalty for temporary files.

agc
  • 7,045
  • 3
  • 23
  • 53
frostschutz
  • 47,228
  • 5
  • 112
  • 159