NAAM
(first writeup) |
(note) |
||
| (17 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | = Nemo's Audio Archive Manager = |
+ | {{TOCright}} |
| + | == Nemo's Audio Archive Manager == |
||
| − | ''I've been to Nam man. It was hell. You're never the same after an experience like that'' |
+ | ''I've been to 'Nam man. It was hell. You're never the same after an experience like that'' |
| − | NAAM is a method of ripping and archiving CD's. (and DVD-A, SACD, etc?) |
+ | NAAM is a procedure for ripping and archiving CDs. (and maybe DVD-A, SACD, etc?) |
| − | It consists of three layers. |
+ | If we consider ones complete media library to consists of three layers thus: |
# Physical Layer. The CD. |
# Physical Layer. The CD. |
||
| − | # Archive Layer. Lossless rip (FLAC) of the CD, plus cached TOC. |
+ | # Archive Layer. Lossless archive of the physical layer |
# Portable Layer. ogg/mp3/etc. These are the files you'd actually USE to play. |
# 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 == |
== Physical Layer == |
||
Not much to see here. It's a CD. Folks. Shiny. |
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. |
||
| + | |||
| + | {{note|center|Old page warning|This page is in the midst of being refactored. All following content is old. oooold and crufty|}} |
||
== Archive Layer == |
== Archive Layer == |
||
| − | The plan is to rip the CD 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. |
+ | 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. Scans of CD booklet artwork would also be stored here in the archive layer. |
+ | 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 == |
== Portable Layer == |
||
| − | Does this need a better name? |
+ | ''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: 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 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 == |
||
| + | * NAAM is named in accordance with [[NINS]] |
||
| + | * Usefull links: http://www.digitalx.org/audio.html |
||
| − | 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!) |
+ | [[Category:NemProject]] |
Latest revision as of 17:06, 27 September 2010
|
[edit] 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:
- Physical Layer. The CD.
- Archive Layer. Lossless archive of the physical layer
- 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)
[edit] 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.
[edit] Old page warningThis page is in the midst of being refactored. All following content is old. oooold and crufty
|
[edit] 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.
[edit] 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: 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
[edit] 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?
[edit] Additional notes
- NAAM is named in accordance with NINS
- Usefull links: http://www.digitalx.org/audio.html
