Daniel James wrote:
>John Ouzts wrote:
>> I want to find the highest peak and normalize
>> it to 0 dB, along with everything else.
>Please forgive me if I've misunderstood you, but this isn't what I
>understand by normalisation. I thought the purpose was to achieve a
>subjective equivalence in level between tracks recorded in different
>situations, and that this roughly equates to normalising the average
>amplitude of each track, using the RMS value.
According to my reading of Bob Katz, _Mastering Audio_, p. 66, normalization
consists of automatically scanning (usually) a block of tracts (usually an
entire album) for the highest peak and raising the level of all tracts
equally, bringing the highest peak to 0 dBFS. He emphasizes that adjusting
relative loudness between tracks must be done by ear (prior to
normalization).
Of course, the programmer determines what any given normalization function
does and the user selects the scope and options used. Katz describes a number
of ways to screw things up.
>> The principal obstacle is
>> the 56+ minute limit on 96/24 *.wav and *.aif files.
>What causes this limitation? Is it a limitation that you've discovered
>in Audacity?
I got out the Katz book to quote from Appendix 2, p. 282:
"A major problem with both WAVE and AIFF file formats is that chunk sizes
(including the overall chunk size of the whole file) use 32 bit integers,
holding the size in bytes." Katz goes on to give maximum lengths for various
sampling rates and bit depths and to cite his source, Richard Dobson on the
Sursound list.
So the problem is a limitation in AIFF and WAVE file formats as written by all
sound editors. Sound Forge 6.0 refuses to save a file in these formats when
it is too large, but the equivalent CoolEdit Pro _silently_ trashes the file.
(This is the reason I use Sound Forge.) Likewise, Audacity 1.2.0(pre1)
appears to save the file in standard *.wav format, but then crashes when it
attempts to open the saved *.wav file. SF has a 64 bit (*.w64) format which
allows the saving of markers with larger files. The problem with this format
is that when the resampled and bit depth reduced files are extracted into
tracks for a CD, the leftover header information causes Roxio and Nero refuse
to accept them for burning to CD. Each track file must be loaded in SF (which
creates a peak file) and resaved without "metadata" in order to be able to
burn the CD. SF tech support says this is NOT fixed in SF 7.0. They seem to
imply this is a problem for Roxio and Nero to fix.
The two paragraphs above represent a lot of painful experience, which I hope
that others starting to work at 96/24 will not have to recapitulate.
John Ouzts
|
