Album Publishing: Dither for 24-bit ?

[tas]

I noticed that in Album Publishing that if you choose the output to be 24 bit wavs, the noise shaping parameter dialog is disabled. This implies that no dithering is taking place? Anyone know if this is true?

[fl]

That's a good question - perhaps it should be directed to support@merging.com for the definitive answer.

My guess is that when dealing with 32 bit floating point material - something Pyramix does all the time, even when the source files have a shorter word length - it gets converted automatically to 24 bit for playback via an integrated task built into the Pyramix processing routines - therefore dithering would be redundant, even when creating 24 bit copies via the Publishing option. Now, my information may be out of date, but I believe that even now, Pyramix performs most of its internal calculations in 32 bit FP precision (and some at 64), and converts automatically to 24 bit (or whatever wordlength the attached audio interface requests) whenever it has to perform for the pesky humans.

The data is stored as 32 bit, allowing you all the computational precision and the "higher than -0 dBFS" headroom you could want, but once you start playback, what you actually hear is equivalent to 24 bits.

[tas]

the thing is that following discussions here what I have been doing lately is bouncing mixdowns to 32-bit files, so that I avoid dithering everytime, (mix and master),
and leave that to the album publishing stage from where I will get both my 24 and 16 bit files. But if what you say Frank is true, then this is not such a good idea?

[Graemme]

Any workstation that uses floating-point for it's internal math has to convert to integer numbers for transmission to the outside world via AES/EBU, etc. Pyramix' output word length is determined by either the mixer for realtime use or the process of the moment (e.g.-mix down or the CD -generation) in non-realtime. (Or both, if you're not paying attention.)

I don't believe the interface has anything to do with 'requesting' the output word length.

It would be simple enough to test all this speculation by null-testing a 32-bit file against it's 24-bit counterpart produced by the album publishing function. If it nulls to -144.5 dB, or so, I'd accept that ;->

That's a good question - perhaps it should be directed to support@merging.com for the definitive answer.

My guess is that when dealing with 32 bit floating point material - something Pyramix does all the time, even when the source files have a shorter word length - it gets converted automatically to 24 bit for playback via an integrated task built into the Pyramix processing routines - therefore dithering would be redundant, even when creating 24 bit copies via the Publishing option. Now, my information may be out of date, but I believe that even now, Pyramix performs most of its internal calculations in 32 bit FP precision (and some at 64), and converts automatically to 24 bit (or whatever wordlength the attached audio interface requests) whenever it has to perform for the pesky humans.

The data is stored as 32 bit, allowing you all the computational precision and the "higher than -0 dBFS" headroom you could want, but once you start playback, what you actually hear is equivalent to 24 bits.

[phaseboy]

I would also just throw out there that there is no reason to be noise-shaping dither applied to a 24bit signal - the fact that noise shaping is not an option is not a red flag.

[fl]

Two things:

Album publishing proceeds in two stages, the first being the creation of a 24 bit MTFF file, from which the various output formats are generated. Because there is no point in Dithering from 24 bit to 24 bit, it's not offered.

Secondly, the level of Dither suitable for 24 bit audio files is probably lower than the thermal atomic noise generated by the components of any audio interface. It's an open question whether a human could distinguish between a dithered and an undithered 24 bit file, at feasible listening levels for most program material. As Mark has pointed out, at these levels, there is really no reason to apply noise shaping.

As for storing files in 32 bitFP format, why not? If you've got the storage space, it's not a bad idea to store things with the highest level of resolution possible, against the eventuality of further processing, by you or by a third party mixing and/or mastering stage. I do the same thing myself when I intend to treat mixes in RX and then bring them back into a Pyramix session - gives the computers more to chew on, presumably with fewer degenerative artifacts.

[DJS]

viewtopic.php?f=4&t=11243

Particularly,
viewtopic.php?f=4&t=11243#p35155

[fl]

Right!

I'd forgotten that you found a way to hack the appropriate file to enable Publishing to create 32 bitFP files.

Since you've made this change already, can you run a quick test for tas's sake (he started this thread)?

Once you've enabled the Publishing routines to create 32 bit MTFF files, does that allow you to select dithering options (on the second page, where you set things up for each output format) when attempting to Publish 24 bit files?

[DJS]

Once you've enabled the Publishing routines to create 32 bit MTFF files, does that allow you to select dithering options (on the second page, where you set things up for each output format) when attempting to Publish 24 bit files?

Not sure I follow. The MTFF bit depth is set on the main dialog page (where I disable dither to produce 32bit MTFF), the second page (album publish dialog) file list is the one you hack to maintain 32bit WAV output files. There has never been any dither settings on that page to my knowledge. Maybe I don't understand the question.