NAAM
Contents |
Nemo's Audio Archive Manager
I've been to 'Nam man. It was hell. You're never the same after an experience like that
NAAM is a procedure for ripping and archiving CD's. (and DVD-A, SACD, etc?)
It consists of three layers.
- Physical Layer. The CD.
- Archive Layer. Lossless rip (FLAC) of the CD, plus cached TOC.
- Portable Layer. ogg/mp3/etc. These are the files you'd actually USE to play.
The aim is to store in the archive layer all the digital data from the physical layer. Bit-for-bit is not important (so iso images aren't needed), but the ability to recreate the basic CD experience in hardcopy later, is. So all audio, track timings, and data is obtained.
Physical Layer
Not much to see here. It's a CD. Folks. Shiny.
More usefully, it probably has a big block of digital audio, and then optionally a data block.
Archive Layer
The plan is to rip the CD audio to a SINGLE flac archive. This ensures no possible seek errors causing overlap or missed audio frames when ending the rip of one track, and the start of the next. Yes, call me paranoid. (Actually, call me paranoid once you find out I also plan to store the final cdparanoia output, so any ripping errors can be quickly noticed).
Along with the audio data would be stored the original CD's TOC, and any digital data that might be on a multi-session disc (as a simple directory of files). Scans of CD booklet artwork would also be stored here in the archive layer. These could be obtained manually, or automated via an amazon CDcover search...
Note: So-called track0 audio (rewind from track1 and find it in negative time) can only be ripped with a capable cdrom with cdparanoia. Also, subchannel data can only be ripped with a capable cdrom, using cdda2wav... cdrdao is untested.
A tagfile of some kind will also be needed, since more detailed information than merely the FreeDB results give may be needed. Tagfile format...?
Flac can store seekpoints - it may be worth generating the flac with seekpoints at the relevant original trackboundaries. Flac can also store an internal cuesheet. This all sounds very neat, and can be altered later with metaflac.
Portable Layer
Does this need a better name?
Anyway, from the archive layer, you have all the information you need to create usable oggs, or mp3s, or whatever. From the stored TOC, a freedb lookup can be performed (in practice, this would be done and cached with the archive layer), the flac transcoded to a lossy format of choice, cut into individual tracks (In the case of ogg, this could be done after encoding. For mp3, it may have to be done before encoding), and stored away from the archive layer. Note also that the archive layer may have both an original TOC (needed for lookups to freedb), and an edited TOC (used for track cutting). This is because sometimes the track boundaries on CD's are poorly timed (example: live CD's where tracks start at the end of the previous track, but at the beginning of the applause for the previous track!)
- For splitting Ogg and MP3's after encoding, see: http://mp3splt.sourceforge.net/
- vcut is a basic ogg cutting tool. It's buggy, and mp3splt has the same code = same bugs
- Feb 2005: New Ogg cutting tool is being developed. Linked when I can
Issues and questions
- How to name the CD's uniquely in filepaths? Seems ideal use for NCDI?
- How to easily and en-masse generate portable files from the archive. Makefiles perhaps?
- Where to store the portable files compared to archive files.
- Would it be usefull to have an 'update tags' command. ie, If the archive tagset got updated, it would update the various comment tags in mp3 or ogg files, without having to re-encode them. Obviously this is possible, but is it worth keeping the archive and portable layers in direct relationship to each other for this?
NAAM is named in accordance with NINS
Usefull links: http://www.digitalx.org/audio.html
