I came across your review of the Digidesign M Box 2 Pro, in which it is stated that a signal indicating -18dBFS should, in professional equipment, produce an output of 0dBu. Later in the piece, the reviewer stated that the actual output of the unit is -12dB, but neglects to say whether that's dBu or dBV. I would be pleased if you could confirm that this is indeed a normal specification.
Secondly, in SOS January 2007's review of the Emu 0404 audio interface, the unit's analogue outputs are specified at +12dBV balanced and +6dBV unbalanced, but there's no mention of source. I assume these are not 'operating levels', and if they are maximums, they are far from impressive. Could you clear that up too?
Lastly, I've seen it stated that recording too hot in digital systems (within, say, -3dBFS) alters the character of the sound, and that we should be operating at -18dBFS. As an electronics engineer, I cannot see that it matters where in the dynamic range you put a digital recording, since the I/O relationship is linear. But I'm willing to believe otherwise, since I am only really familiar with analogue.
Technical Editor Hugh Robjohns replies: In answer to your first question, you're correct in thinking that 0dBu is equal to -18dBFS in professional equipment. This is the European Broadcasting Union (EBU) standard alignment, officially called R68, and we have mentioned it in numerous SOS articles, particularly those concerned with A-D/D-A converters, and metering, such as the one in SOS June 2000. In America they use a different standard, known to some as RP155, where +4dBu equals -20dBFS. (This standard thus offers 6dB more headroom.) This is specified by the Society of Motion Picture and Television Engineers (SMPTE).
Regarding the information about the M Box 2, I believe the reviewer was referring to dBu measurements. He most probably discovered that the unit is calibrated to provide a semi-professional standard output level. The professional standard reference is +4dBu, while the semi-pro reference is -10dBV, and, because these two figures use different reference points, there is just under 12dB of difference between the two.
The Emu 0404 also appears to be set up as a semi-professional unit, and the figures you quote are peak levels, although they're specified in an unusual way. The figure +12dBV is about 4V and equivalent to roughly +14dBu. The implication of using the dBV reference is that the nominal level is -10dBV, and therefore suggests that the alignment is set to the equally unusual '-22dBFS = -10dBV' reference.
To address your last point, about recording in the topmost part of the digital audio spectrum: assuming correct dithering is taking place the I/O relationship in a digital system should be linear, as you suggest. But headroom is still important in many digital processing applications. In the good old analogue days, a professional mixing console was designed to work with a nominal level of 0dBu or +4dBu. Peak signal levels were generally constrained by hand or limiter to about 8dB above that nominal level, maybe +12dB if people wanted to record 'hot'. But the clipping point of the console was a good +24dBu in most cases, sometimes 4dB more; that headroom was essential to allow the passage of brief, high-level transients that weren't visible on the meters.
When working with 24-bit digital systems, it makes absolute sense to maintain a very similar gain structure and headroom, for both technical and operational convenience. That means building in typically about 20dB of headroom above the nominal signal level, with most peaks reaching no higher than about -10dBFS. Only the rarest fast transients should kick up above that. When working in this way, the system noise floor will still be a good 90-100dB below the nominal level, which is directly comparable with a good-quality analogue console.
Operationally, working with this kind of headroom contingency means no longer having to worry about clipping and overloads, and internal mixing and signal processing generally sounds cleaner and more analogue-like because you are not forcing the system to use floating-point maths (not all systems appear to work correctly in this regard).