Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[r010159]

Does JRiver MC dither when it converts numbers from the 64-bit internal format to 24-bit output? Or does it just truncate the least significant bits?

[Hendrik]

Output is dithered when down-converting.

[6233638]

There are apparently issues with the current Mac implementation:
 
http://yabb.jriver.com/interact/index.php?topic=84694.msg600199#msg600199

[Hendrik]

I don't know how that works in Macs, but that would only ever be a problem when you have to send the DAC 32-bit, but the DAC then only reads 24-bit out of the signal, instead of the DAC directly getting 24-bit to begin with.
Also, dithering in such a case doesn't necessarily mean that the remaining bits all turn to zero, depending on how its implemented.

[r010159]

Dithering to 24-bits IMO is unnecessary. Just truncate the lowest significant bits. The loss in audio information very probably cannot be heard. But if dithering is actually used, this can have different results depending on the dithering algorithm used. Then no bit-perfect player which does this can claim to be as such when dithering is used.

This is the $64,000 question. For IMO this would be the only thing that separates one player from another, except for sample rate conversions. I will not get into the meaninglessness of integer mode. Now if DSP is being used...

[JimH]

You might find this thread interesting:

http://yabb.jriver.com/interact/index.php?topic=76912.0

[groovyd]

Dither the LSB after truncating form say 32 bit to 24 can only increase noise.  Theoretically optimal solution is simple truncation.

[r010159]

Quite an interesting post there! For those reasons, does J River for the Mac implement dithering to 24-bit values? Apparently that option has been given to the Windows PC world.

Yes, from my discussions with you, groovyd, on another website, truncation is supposed to be the optimal solution for the conversion, because none can hear the differences to that bit-depth.  You gave me a convincing argument. But that audio engineer is providing interesting feedback nonetheless. Oh how I do like wading through the messiness involved with determining what is possible from what can be theoretically proven.

I just offered my question to see what the developer of J River is convinced of being valid.

Bob

EDIT: It appears that in a discussion with Bob Katz, Matt did indicate the data is dithered when converted to 24-bit integers. This is separate from the question whether dithering is necessary. So much for bit-perfect playback. So I guess the real question is how good of a job the software does with dithering to produce the least amount of audible artifacts, that is if there will be any at all, making dithering irrelevant.

EDIT (again): I just realized most sources available will be 16-bit. So for this type of source, I think all of this is irrelevant.

[Hendrik]

Then no bit-perfect player which does this can claim to be as such when dithering is used.

If you cut off data, its obviously not bit-perfect anymore either, since you lost bits.
Dithering results in a mathematical result closer to the original than pure truncation.

Its important to note that proper dithering doesn't modify the audio signal if it doesn't need to. If you play a 24-bit file with 24-bit output at 100% volume and without any processing, then the dithering does not modify the audio at all, and you achieve bit-perfect playback.

[groovyd]

At least from my signal processing background I know for certain that truncation is your optimal solution as dithering will only add noise to the signal.  It would be impossible for a truly random dithering to occur which means that you end up adding the noise signature of the dithering to the original spectrum where it is not perfect white noise.  In any case it makes no sense to do it since even if it were perfect white noise it can be no more accurate then simple truncation.  You cannot add information to the result if you do not have that information to begin with. The only improvement you can make is to perform a nearest rounding of the truncated bits rather then simply throwing them away, but this isn't really 'dithering' per-say.

[mwillems]

At least from my signal processing background I know for certain that truncation is your optimal solution as dithering will only add noise to the signal.  It would be impossible for a truly random dithering to occur which means that you end up adding the noise signature of the dithering to the original spectrum where it is not perfect white noise.  In any case it makes no sense to do it since even if it were perfect white noise it can be no more accurate then simple truncation.  You cannot add information to the result if you do not have that information to begin with. The only improvement you can make is to perform a nearest rounding of the truncated bits rather then simply throwing them away, but this is really 'dithering' per-say.

You should check out the chapter in Bob Katz's "Mastering Audio" about dithering.  He makes a very good case for how dithering can actually increase the effective dynamic range (when compared to truncation), and preserve more of the signal than truncation when processing takes place.  He explains it far better than I ever could (I'm not an audio engineer), but the mathematical argument seems pretty clear that dithering can produce a better outcome than truncation when the signal is being changed.  

If you checked out the thread Jim linked above, you can see that Bob was involved in helping test and sort out JRiver's dithering procedures, and you can get a flavor of what he has to say in his book.

When there's no changes to the signal, JRiver doesn't dither (preserving bitperfect output)
http://yabb.jriver.com/interact/index.php?topic=80522.msg548095#msg548095
http://yabb.jriver.com/interact/index.php?topic=76912.msg521838#msg521838