The No.1 Website for Pro Audio
Lossy Files Made from 24 bit vs 16 bit WAVs?
Old 2 weeks ago
  #1
Lives for gear
 
Trakworx's Avatar
Lossy Files Made from 24 bit vs 16 bit WAVs?

Does it really matter?

Is it just the noise floor or is there another sonic difference?

I don't notice any significant difference just by listening...

I know some of you understand how codecs work. What's the dealio?

Thanks!
Old 2 weeks ago
  #2
Lives for gear
 
SmoothTone's Avatar
 

Verified Member
When I tested this there was more in the null between an mp3 made from 24 and 16bit than I expected. File attached.

While way down the list of priorities in terms of audible importance, good practice is good practice I guess.
Attached Files

null of 24 & 16 bit to 320k mp3.wav (6.82 MB, 570 views)

Old 2 weeks ago
  #3
Lives for gear
 
Trakworx's Avatar
Quote:
Originally Posted by SmoothTone View Post
When I tested this there was more in the null between an mp3 made from 24 and 16bit than I expected. File attached.

While way down the list of priorities in terms of audible importance, good practice is good practice I guess.
Wow that is a lot in the null!

You inspired me to do my own null test and I got a similar result. Yet I still can't hear the difference in a blind listening test... Hmm.
Old 2 weeks ago
  #4
Lives for gear
 
SmoothTone's Avatar
 

Verified Member
Quote:
Originally Posted by Trakworx View Post
Yet I still can't hear the difference in a blind listening test... Hmm.
Me neither. That's the magic of perceptual masking I s'pose.
Old 2 weeks ago
  #5
Lives for gear
 
Hippocratic Mastering's Avatar
Caveat: I haven't listened to the files or performed my own test.

Just because there's a lot in the null, does that necessarily mean anything? 'Different' and 'better' are not the same. I'm not being glib or dismissing your findings, just trying to further the discussion.
Old 2 weeks ago
  #6
Lives for gear
 
SmoothTone's Avatar
 

Verified Member
To me this is in the category of "good practice that makes no audible difference in most listening scenarios."

Given the choice, I'll use a 24bit source, but I have no trouble sleeping if I make an mp3 from a 16bit file.
Old 2 weeks ago
  #7
Gear Addict
 
Magnus Lindberg's Avatar
 

https://www.youtube.com/watch?v=2iDrbgfPjPY

Not so certain that 24bit (or 32) is better practice, check the end. Anyhow, I couldnt care less...but still I am writing this reply


Quote:
Originally Posted by SmoothTone View Post
To me this is in the category of "good practice that makes no audible difference in most listening scenarios."

Given the choice, I'll use a 24bit source, but I have no trouble sleeping if I make an mp3 from a 16bit file.
Old 2 weeks ago
  #8
Lives for gear
 

Verified Member
A good listening test is to AB both mp3 while altering them (with eq for example).
It will change the relationship between the different elements masking each other and you'll start to hear the artifact of the process.
Old 2 weeks ago
  #9
Lives for gear
 
Hippocratic Mastering's Avatar
Quote:
Originally Posted by Saxnscratch View Post
A good listening test is to AB both mp3 while altering them (with eq for example).
It will change the relationship between the different elements masking each other and you'll start to hear the artifact of the process.
Nice tip!
Old 2 weeks ago
  #10
Lives for gear
 
mastermat's Avatar
 

Quote:
Originally Posted by Magnus Lindberg View Post
https://www.youtube.com/watch?v=2iDrbgfPjPY

Not so certain that 24bit (or 32) is better practice, check the end. Anyhow, I couldnt care less...but still I am writing this reply
thanks for this useful information, much appreciated!
Old 2 weeks ago
  #11
Lives for gear
 
Trakworx's Avatar
Quote:
Originally Posted by Magnus Lindberg View Post
https://www.youtube.com/watch?v=2iDrbgfPjPY

Not so certain that 24bit (or 32) is better practice, check the end. Anyhow, I couldnt care less...but still I am writing this reply
Thanks for that!

The well reasoned conclusion he draws at 21:12 - 21:37 in the video:

"It's probably a safer bet to encode MP3s from a 16 bit dithered file."

... is very interesting ... because of what happens in the MP3 decoder when the MP3 is played back ...
Old 2 weeks ago
  #12
Lives for gear
 
SmoothTone's Avatar
 

Verified Member
Quote:
Originally Posted by Saxnscratch View Post
A good listening test is to AB both mp3 while altering them (with eq for example).
It will change the relationship between the different elements masking each other and you'll start to hear the artifact of the process.
Great tip!
Old 2 weeks ago
  #13
Lives for gear
 
SmoothTone's Avatar
 

Verified Member
Quote:
Originally Posted by Magnus Lindberg View Post
https://www.youtube.com/watch?v=2iDrbgfPjPY

Not so certain that 24bit (or 32) is better practice, check the end. Anyhow, I couldnt care less...but still I am writing this reply
This is very interesting. . . And somewhat perplexing. My understanding was that dither was properly handled by the decoder.

To be fair, it appears that Dan is basing his conclusion on how this one version of Sound Forge handles the decoding. I'm curious about consumer decoders now.

Again, yes, we're in the realm of the 'mostly inaudible.' I just like to understand how things work.
Old 2 weeks ago
  #14
Lives for gear
 
Justin P.'s Avatar
 

Verified Member
Quote:
Originally Posted by SmoothTone View Post
Dan is basing his conclusion on how this one version of Sound Forge handles the decoding. I'm curious about consumer decoders now.
I've been thinking about this too. At risk of sounding like a moron, do consumer media players need to decode to play back mp3?

Probably if it has to be PCM audio to get out of the DAC but it did have me wondering how iTunes, Windows Media Player, and other consumer players handle lossy playback and decoding (if needed), and how their built-in level controls factor in.

In my studio I always keep the outputs of iTunes/TIDAL/J River at full and adjust playback with my monitor controller but when we're on mobile devices casually listening, we usually have to use the level control of the device and/or software.

Maybe I'll eat my words but I'm not convinced from this one example.

I do respect Dan and the rest of the dither examples in his video are very well done. I will show this in my mastering class. I just don't know if Sound Forge is a conclusive way to decide if dither for mp3 encoding is best.
Old 2 weeks ago
  #15
Lives for gear
 
FabienTDR's Avatar
 

Verified Member
Interesting experiment!

I agree with Hippocratic Mastering, though. Just because the resulting mp3 is different doesn't mean the results are better.
Old 2 weeks ago
  #16
Lives for gear
 
SmoothTone's Avatar
 

Verified Member
Quote:
Originally Posted by Justin P. View Post
do consumer media players need to decode to play back mp3?
Yep. I assume for the reason you stated.

I had some time to look into this a bit more today (sitting in a waiting room for a couple of hours).

I looked at the ISO/IEC technical documents [1, 2] that describe the standard for audio coding. Dither is not mentioned at all. The only mention of wordlength says that audio input/output can be up to 24bits. So it seems it is up to the specific decoder to decide what wordlength the reconstructed PCM will be and whether dither is applied. It is this last step (that is not defined by the standard) that has the potential to degrade the accuracy of the PCM output.

The specifications on the encoder side seem to allow a lot of scope for variations in how encoding is implemented. Decoders, however, are supposed to meet a carefully defined standard to ensure usable output. Tests of various decoders [3, 4, 5] demonstrated that they don’t all meet the standard.

It seems that, like a lot of these things, the answer to whether 24bit is better than 16bit for lossy encoding is "it depends." Because of the variation in encoders and decoders, any of the following could be true in different scenarios:
  • Different decoders could output different wordlengths, dithered or not.
  • 24bit input could result in more decoded dynamic range.
  • Encoders may actually perform better at 16bit if designed that way.
  • Dithered 16bit input could result in better decoded PCM if the decoder truncates to 16bit at output.
  • Dither could be broken and rendered useless by the floating point encoder.

Reaper developer and Bitter (and dither vst) creator, ‘Schwa,’ is adamant that dither is not required. The mp3 output from Reaper in Dan's video supports this. RX7 decodes mp3 files as 32bit floating point. But the Sound Forge decoder in Dan’s video outputs truncated 16bit PCM. How many other decoders do this also?

So the main question is: will the decoder truncate the output? Dan's test shows it's not safe to assume it won't. If at least one decoder truncates to 16bit, then Dan is correct that it is 'safest' to feed the encoder a dithered 16bit file. Furthermore, Dan's example demonstrates that the dither can make it through the lossy process and still serve its function.

AND. . . none of this really makes an audible difference in our listeners' worlds!


Quote:
Maybe I'll eat my words but I'm not convinced from this one example. . . I just don't know if Sound Forge is a conclusive way to decide if dither for mp3 encoding is best.
I have to say, after looking at all this, I'm now leaning towards Dan's conclusion of dithered 16bit being the safest option. Which is good news, since most aggregators still only accept 16/44.1.
Old 2 weeks ago
  #17
Lives for gear
 
Justin P.'s Avatar
 

Verified Member
@ SmoothTone

Thanks for digging up all that info. Now we know. Also, it's no wonder that even though mp3 encoding itself pads the files with a few milliseconds of silence, that we have so much trouble with gapless playback in certain media players. The latest versions of iTunes can't even reliably play gapless WAVs without a hiccup.

J River is the most reliable consumer-ish media player I've found for various real-world testing.

Anyway, FWIW, an mp3 (320 Fraunhofer) encoded from floating point audio in WaveLab, is decoded to 32-bit floating point WAV when imported back into WaveLab, and there is indeed 32-bits of info. See image.

It seems like this is very app/software dependent on the decode side.
Attached Thumbnails
Lossy Files Made from 24 bit vs 16 bit WAVs?-screen-shot-2020-02-13-6.52.36-am.jpg  
Old 2 weeks ago
  #18
Lives for gear
 

Verified Member
Quote:
Originally Posted by SmoothTone View Post
......
......

AND. . . none of this really makes an audible difference in our listeners' worlds!


I have to say, after looking at all this, I'm now leaning towards Dan's conclusion of dithered 16bit being the safest option. Which is good news, since most aggregators still only accept 16/44.1.
Thank you for the work !!

Also, it's great to have people who care where pretty much no one does
Old 2 weeks ago
  #19
Lives for gear
 
zmix's Avatar
 

Quote:
Originally Posted by SmoothTone View Post
When I tested this there was more in the null between an mp3 made from 24 and 16bit than I expected. File attached.

While way down the list of priorities in terms of audible importance, good practice is good practice I guess.

Have you tried a null between two MP3s generated from the *same* 24 or 16 bit source?
Old 2 weeks ago
  #20
Lives for gear
 
Trakworx's Avatar
Quote:
Originally Posted by zmix View Post
Have you tried a null between two MP3s generated from the *same* 24 or 16 bit source?
I did. They nulled.
Old 2 weeks ago
  #21
Lives for gear
 
Trakworx's Avatar
Quote:
Originally Posted by SmoothTone View Post
...

So the main question is: will the decoder truncate the output? Dan's test shows it's not safe to assume it won't. If at least one decoder truncates to 16bit, then Dan is correct that it is 'safest' to feed the encoder a dithered 16bit file. Furthermore, Dan's example demonstrates that the dither can make it through the lossy process and still serve its function.

AND. . . none of this really makes an audible difference in our listeners' worlds!




I have to say, after looking at all this, I'm now leaning towards Dan's conclusion of dithered 16bit being the safest option. Which is good news, since most aggregators still only accept 16/44.1.
Thank you for taking the time to dig into that!
Old 2 weeks ago
  #22
Lives for gear
 
SmoothTone's Avatar
 

Verified Member
Quote:
Originally Posted by Justin P. View Post
Also, it's no wonder that even though mp3 encoding itself pads the files with a few milliseconds of silence, that we have so much trouble with gapless playback in certain media players. The latest versions of iTunes can't even reliably play gapless WAVs without a hiccup.
I discovered yesterday that this is because different encoders have different padding and don't 'communicate' to the decoder what it is. It seems that LAME is one encoder that includes a metadata tag to specify the gap which a LAME decoder can use to remove the padding on output, allowing for gapless audio. Imagine if this were standard!

Quote:
It seems like this is very app/software dependent on the decode side.
Indeed it does. Another example of how unregulated our industry is.
Old 2 weeks ago
  #23
Lives for gear
 
SmoothTone's Avatar
 

Verified Member
Quote:
Originally Posted by Trakworx View Post
Thank you for taking the time to dig into that!
Thankyou for starting threads like this Justin. I like that they challenge my assumptions.
Old 2 weeks ago
  #24
Motown legend
 
Bob Olhsson's Avatar
 

Verified Member
I've wondered why the Sonnox ProCodec dithers audio to 16 bits before encoding. Maybe they did the same tests.
Old 1 week ago
  #25
Lives for gear
 
Trakworx's Avatar
Quote:
Originally Posted by Bob Olhsson View Post
I've wondered why the Sonnox ProCodec dithers audio to 16 bits before encoding. Maybe they did the same tests.
Now that you mention it, I now see that Pro Tools MP3 encoder automatically switches to 16 bit and disables the bit depth menu. Which means I've been making MP3s from 16 bit files all along!

I think both PT and Sonnox use Fraunhofer...

P.S. But Snapper says the resulting 320kbps MP3s are "Word Size: 32 bits float"... And If I go to import the same MP3 into Pro Tools it says "Bit Depth: 16". Hmmm...
Old 1 week ago
  #26
Lives for gear
 
SmoothTone's Avatar
 

Verified Member
Quote:
Originally Posted by Trakworx View Post
P.S. But Snapper says the resulting 320kbps MP3s are "Word Size: 32 bits float"... And If I go to import the same MP3 into Pro Tools it says "Bit Depth: 16". Hmmm...
The encoded data-compressed bitstream is floating point. How it gets decoded back to pcm is up to the 'interpretation' of the decoder.

Last edited by SmoothTone; 1 week ago at 12:41 AM.. Reason: for accuracy
Topic:
Post Reply

Welcome to the Gearslutz Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…
Thread Tools
Search this Thread
Search this Thread:

Advanced Search
Forum Jump
Forum Jump