From ThorxWiki
Jump to: navigation, search


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 CDs. (and maybe DVD-A, SACD, etc?)

If we consider ones complete media library to consists of three layers thus:

  1. Physical Layer. The CD.
  2. Archive Layer. Lossless archive of the physical layer
  3. Portable Layer. ogg/mp3/etc. These are the files you'd actually USE to play.

The Physical and Portable layers are obvious. NAAM is all about the Archive layer.

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 data is obtained:

  • Audio (including so-called Track 0)
  • Track data and sub-track index data from the TOC
  • subchannel data (this is where CD-TEXT extensions can reside for example)
  • lead-in data (may also contain CD-TEXT data)
  • Digital data (ie, ISO9660 or UDF data)

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.

If we decide to extend NAAM for SACD or DVD-A, we should revisit this then.

Old page warning

This page is in the midst of being refactored. All following content is old. oooold and crufty

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 CDs 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 CDs are poorly timed (example: live CDs 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 MP3s after encoding, see:
  • 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 CDs 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?

Additional notes

Personal tools

meta navigation
More thorx