Update page 'Home'
commit
8baabbe392
|
@ -0,0 +1,62 @@
|
||||||
|
# About the NRG image format
|
||||||
|
|
||||||
|
A good reference about the metadata format is the corresponding Wikipedia
|
||||||
|
article: <https://en.wikipedia.org/wiki/NRG_(file_format)>.
|
||||||
|
|
||||||
|
The source code and comments of NRGrip also provide some information, of
|
||||||
|
course.
|
||||||
|
|
||||||
|
|
||||||
|
# Manual audio data extraction howto
|
||||||
|
|
||||||
|
Just for fun, it is possible to extract manually the audio data from an NRG
|
||||||
|
image, after displaying its metadata with NRGrip. You will need to know:
|
||||||
|
|
||||||
|
- The first audio byte (`dd skip`):
|
||||||
|
`daox.first_track.index1` (or `index0` if you wish to include the pre-gap)
|
||||||
|
|
||||||
|
- The last audio byte:
|
||||||
|
`daox.last_track.end_of_track`
|
||||||
|
|
||||||
|
- The number of audio bytes (`dd count`):
|
||||||
|
`Last audio byte - First audio byte`
|
||||||
|
|
||||||
|
To extract the raw audio data (substitute `${FIRST_AUDIO_BYTE}` and
|
||||||
|
`${NB_AUDIO_BYTES}` with the numbers found above:
|
||||||
|
|
||||||
|
dd iflag=count_bytes,skip_bytes if=image.nrg of=image.raw \
|
||||||
|
bs=4M skip=${FIRST_AUDIO_BYTE} count=${NB_AUDIO_BYTES}
|
||||||
|
|
||||||
|
|
||||||
|
# Notes on cue sheet extraction
|
||||||
|
|
||||||
|
From Wikipedia:
|
||||||
|
|
||||||
|
- A CD can contain up to 99 tracks.
|
||||||
|
- Each track can in turn have up to 100 indexes.
|
||||||
|
- The vast majority of songs are recorded under index 1, with the pre-gap being
|
||||||
|
index 0.
|
||||||
|
- Sometimes hidden tracks are placed at the end of the last track of the disc,
|
||||||
|
often using index 2 or 3.
|
||||||
|
- In an NRG cue sheet, the _index0_ points are present even when they are
|
||||||
|
identical to the _index1_ ones.
|
||||||
|
- The _index0_ points in audio tracks are incorrect if Nero has been asked to
|
||||||
|
record all the sub-channel data (in that case the sector size is 2448 bytes).
|
||||||
|
- No index other than 0 or 1 has been encountered, although the chunk format
|
||||||
|
allows for such cue points to be recorded; thus the number of cue blocks seems
|
||||||
|
to always be `2 * (number of tracks + 1)`: two indices for each track, an
|
||||||
|
_index0_ for the lead-in and an _index1_ for the lead-out.
|
||||||
|
|
||||||
|
From this information and other observations:
|
||||||
|
|
||||||
|
- The cue sheet should include all the indices for each track, but _index0_
|
||||||
|
should be ignored if:
|
||||||
|
- _index0_ = _index1_, or
|
||||||
|
- _index0_'s position is negative.
|
||||||
|
- It is possible to have incoherent track numbering (observed: track 10 is
|
||||||
|
numbered 16 in CUEX).
|
||||||
|
- The lead-in area (track 0) and the lead-out area (track 0xAA) should not
|
||||||
|
appear in the cue sheet.
|
||||||
|
|
||||||
|
How will multi-session CDs be handled? Is it worth implementing, since
|
||||||
|
multi-session audio CDs must be very rare?
|
Loading…
Reference in New Issue