[Deltrus]

  I have no idea what the technical difference between the two files is, or if the test is even valid.  All I know is that I can reliably pass it.  I cannot do the same for the Gangam Style test.

16 bit to 8 bit is not 16 bit to 24 bit... I hope you understand this?

 

[Computerpro3]

  16 bit to 8 bit is not 16 bit to 24 bit... I hope you understand this?

Gee, I thought they were all the same and we were just using different numbers for fun.  

 

 

[VNandor]

  I have no idea what the technical difference between the two files is, or if the test is even valid.  All I know is that I can reliably pass it.  I cannot do the same for the Gangam Style test.

That's what I call a screenshot! Is that aliasing I see?

 
Anyways going by the look of the test, the only thing that changes is the bit depth. The youtube version of gangam style "looks" compressed (the peak meter of windows' mixer is being around at 0dB and doesn't move a lot). This might explain why 8 bit sounds close to the 16 bit version. Less "dynamic range" takes less bits to encode properly. I could take closer look if you linked to the test but all I could do is to perform a null test to see if the difference between the two versions is just noise. People with better softwares and better understanding might be able to confirm that the only difference is just the bit depth or there's something else going on as well.

 

[RRod]

  That's what I call a screenshot! Is that aliasing I see?

 
Anyways going by the look of the test, the only thing that changes is the bit depth. The youtube version of gangam style "looks" compressed (the peak meter of windows' mixer is being around at 0dB and doesn't move a lot). This might explain why 8 bit sounds close to the 16 bit version. Less "dynamic range" takes less bits to encode properly. I could take closer look if you linked to the test but all I could do is to perform a null test to see if the difference between the two versions is just noise. People with better softwares and better understanding might be able to confirm that the only difference is just the bit depth or there's something else going on as well.

 
8-bit truncation errors are ~48dB down from 0dBFS, assuming no dither. Many people can't seem to pick it out in a loud clip such as the NY example, but it's not surprising if someone listening intently at high volume might be able to do it.

 

[globobock]

Allow me a question of the naivest order...
 
In your studio mixing experiences, what is the actual "True relevant" frequency range for music? I know that the human ear can th(theoretically) reach 20K, but in reality 17K is where most reach their limits.
 
Based on innerfidelity graphs, most headphones start to roll off at 10K.
 
Is there a table that shows the freq range for vocals and different instruments?

 

[dimedrol]

google helps a lot with instruments frequency:

http://www.independentrecording.net/irn/resources/freqchart/main_display.htm

 

[Brooko]

  Is there a table that shows the freq range for vocals and different instruments?

 
http://www.independentrecording.net/irn/resources/freqchart/main_display.htm

 

[StanD]

This link should scare the cr@p out of every audiophile worrying about the high freq roll off in headphones. Apparently women are superior.
https://www.osha.gov/pls/oshaweb/owadisp.show_document?p_table=STANDARDS&p_id=9741

 

[gregorio]

  The youtube version of gangam style "looks" compressed (the peak meter of windows' mixer is being around at 0dB and doesn't move a lot).

 
A fact which many audiophiles appear completely unaware of is that pretty much all the main streaming service apply loudness normalisation. For about the last two years everything uploaded to YouTube is automatically loudness normalised to the equivalent of about 13.5LUFS and they've since been working on applying this loudness normalisation to content uploaded previously. Youtube is the worst of the streaming services as far as I'm aware, Apple Radio is normalised to the equivalent of about 16.5LUFS for example. I say "about" because no one outside of each of the companies know exactly how they're achieving their normalisation but particularly with YouTube (with such a high normalisation level) the process must often include compression.
 

  8-bit truncation errors are ~48dB down from 0dBFS, assuming no dither.

 
Truncation errors occur in the LSB so with 8bit that would be at ~42dB down from 0dBFS and it doesn't really matter whether we assume dithering or not. I'm sure you probably realise this but just thought I'd be a bit pedantic about it!
 
Quote:

  In your studio mixing experiences, what is the actual "True relevant" frequency range for music? I know that the human ear can th(theoretically) reach 20K, but in reality 17K is where most reach their limits.

 
Even near perfect human hearing starts rolling off steeply from about 12kHz AND ON TOP OF THIS, most acoustic instruments also produce decreasing level output (of harmonics) from around 8kHz or lower. IME, there is very little relevance beyond about 16kHz. Vinyl is also particularly attenuated/inaccurate by 16kHz and until about 15-20 years ago TV broadcast was limited to 15kHz. Having said this, I do check what's going on above 16kHz (just in case) but I have to check with a spectrogram as I can't hear that high any more.
 
G

 

[RRod]

  Truncation errors occur in the LSB so with 8bit that would be at ~42dB down from 0dBFS and it doesn't really matter whether we assume dithering or not. I'm sure you probably realise this but just thought I'd be a bit pedantic about it!

 
Perhaps I am misusing the term "truncation error" then. If you truncate a 16-bit file down to 8-bit and then pad it back up, the difference in the two signals will peak at -48dB. My point with dither was that a difference file made in the same way will have higher peaks if dither was used.

 

[Computerpro3]

"
A fact which many audiophiles appear completely unaware of is that pretty much all the main streaming service apply loudness normalisation. For about the last two years everything uploaded to YouTube is automatically loudness normalised to the equivalent of about 13.5LUFS and they've since been working on applying this loudness normalisation to content uploaded previously. Youtube is the worst of the streaming services as far as I'm aware, Apple Radio is normalised to the equivalent of about 16.5LUFS for example. I say "about" because no one outside of each of the companies know exactly how they're achieving their normalisation but particularly with YouTube (with such a high normalisation level) the process must often include compression."
 
I do believe Tidal has an option to disable this.  I have been impressed with the quality vs. Spotify.  The difference is fairly noticeable on well recorded classical music.

 

[gregorio]

  Perhaps I am misusing the term "truncation error" then. If you truncate a 16-bit file down to 8-bit and then pad it back up, the difference in the two signals will peak at -48dB. My point with dither was that a difference file made in the same way will have higher peaks if dither was used.

 
I'm not sure if you're misusing the term, I think so, I'm trying to get my head around the implications of your test. If you truncate to 8bit, you'll get truncation error in the 8th bit and truncation error is correlated to the signal. Applying dither in theory randomises (decorrelates) this error, so what you'll end up with when using dither is the same amount of error (level) but distributed evenly as white noise rather than as spikes at particular frequencies. I say in theory because in practise dither is often applied at a somewhat higher level than the level of the truncation error, particularly in the case of noise-shaped dither.
 
If I'm understanding your test, below -48dB in the 8bit padded version you'll just have digital silence (zeros in the last 8bits) as compared to non-zero data in some of the 8 LSBs in the original, an obvious numerical difference. However, truncation error will be occurring in the 8th bit and although not obvious numerically (because like the original it will contain non-zero values at times), you should get a difference measurable up to -42dB, the same as if you applied a perfect 1 LSB dither. With noise-shaped dither you'd almost certainly get a difference file which is higher, probably around -38dB but of course, it would depend on the actual settings of the dither applied. Dither is not such a complex process to get one's head around but like many things in audio, it's a bit of a rabbit hole when we start looking in detail at it's practical application. For example, we have to think about the application of dither in quite different terms when reducing bit depth to 16bit as compared to reducing it to 8bit.
 

 
I do believe Tidal has an option to disable this.

 
Good to know. Apple, Youtube and the others I'm aware of don't have such an option. Hopefully they'll all (including Tidal) eventually come into line with the AES recommendations and standardise to -15LUFS and make sure it can't be turned off!
 
G

 

[RRod]

   
I'm not sure if you're misusing the term, I think so, I'm trying to get my head around the implications of your test. If you truncate to 8bit, you'll get truncation error in the 8th bit and truncation error is correlated to the signal. Applying dither in theory randomises (decorrelates) this error, so what you'll end up with when using dither is the same amount of error (level) but distributed evenly as white noise rather than as spikes at particular frequencies. I say in theory because in practise dither is often applied at a somewhat higher level than the level of the truncation error, particularly in the case of noise-shaped dither.
 
If I'm understanding your test, below -48dB in the 8bit padded version you'll just have digital silence (zeros in the last 8bits) as compared to non-zero data in some of the 8 LSBs in the original, an obvious numerical difference. However, truncation error will be occurring in the 8th bit and although not obvious numerically (because like the original it will contain non-zero values at times), you should get a difference measurable up to -42dB, the same as if you applied a perfect 1 LSB dither. With noise-shaped dither you'd almost certainly get a difference file which is higher, probably around -38dB but of course, it would depend on the actual settings of the dither applied. Dither is not such a complex process to get one's head around but like many things in audio, it's a bit of a rabbit hole when we start looking in detail at it's practical application. For example, we have to think about the application of dither in quite different terms when reducing bit depth to 16bit as compared to reducing it to 8bit.
 

 
I see what you are saying. The reason I think about it in terms of the difference is that the 8 bits you have left after pure truncation are unaltered, so they don't have any error in terms of their own values. The errors are in the 8 bits that are now zeros that might have had content, and the loudest they can get is -48dB (that is, the decimal values for the difference will be in [-128,128]). Agree with you on the actual complexity of dither. I bring it up in an 8bit context because I find that 8bit non-shaped dither can actually audibly stand out more than pure 8bit truncation errors in the version that is applied by SoX, for example. Sorry for boring everyone to death ^_^

 

[gregorio]

  [1] The reason I think about it in terms of the difference is that the 8 bits you have left after pure truncation are unaltered, so they don't have any error in terms of their own values.
[2] The errors are in the 8 bits that are now zeros that might have had content, and the loudest they can get is -48dB (that is, the decimal values for the difference will be in [-128,128]).

 
OK, I think I understand your reasoning now. However, I don't believe it's valid in practice and the end result is that you appear to be confusing truncation error with quantisation error, which is quite common because truncation error is a form of quantisation error. 

If you hack off the last 8 bits of a 16bit file then yes, the remaining 8bits will be numerically identical to the 8 MSBs in the 16bit file and the only numerical difference would be between what was in the 8 LSBs of the 16bit original and nothing (the 8 zeros in the 8 LSBs of our padded 8bit file). However, you seem to be forgetting/ignoring what these numerical values actually represent, which is effectively co-ordinates, which when fed into a sinc function will recreate a continuous wave form. In the case of quantisation error, the difference between the actual (original) value and our available (quantisation) values results in an error signal which is fairly uniformly distributed (in both time and frequency) and isn't significantly correlated to the input signal. Feeding this into a sinc function will result in a perfect recreation of our waveform plus a fairly random amount of all other frequencies (of nearly equal intensity), IE. A perfect signal + fairly constant (nearly white) noise. Truncation distortion on the other hand has a non-uniform distribution and is significantly correlated with the input signal. Feed this into a sinc function and we'll get quite different results, the error is concentrated into fewer frequencies and time related with the signal (not constant). IE. A perfect signal plus some spurious tones. It doesn't really sound like that though, these tones are related to the input signal but not harmonically related, so it actually sounds somewhat similar to digital clipping distortion. As an example, let's say it were possible to make two recordings which were absolutely identical in all respects except that one had a bit depth of 16bit and the other 8bit. Using your reasoning, if we truncate the 16bit version to 8 bits the result would be bit perfect identical with our 8bit recording but this isn't the result we'd get, they wouldn't be bit perfect identical and what came out of the DAC would be significantly different.
 
1. Due to the above, this statement is in fact incorrect. The 8 bits you've got left after truncation maybe numerically identical to the first 8 MSBs of the 16bit original but it definitely does have "error in terms of their own values", it has truncation error!
 
2. I see where you're coming from (numerically) but this statement isn't correct either. What you're effectively saying is that the loudest that nothing (digital silence) can get in a truncated 8bit file is -48dB, which is true in a sense but is unrelated to the loudest that the error can get by truncating those 8 bits. If we're looking at the actual error caused by hacking those 8 bits off, rather than just at the 8 bits which no longer exist, then with truncation we could end up with error peaks as high as -36dB or so and what's more, it could sound higher than it's level suggests due to our ears' sensitivity to this type of non-harmonic distortion.
 
G

 

[RRod]

So indeed, if I mock up reconstruction using SoX (resample to some ungodly high rate and keep things at 32 bits), the difference between the reconstructions of the original file and the 8-bit version end up peaking at -42. I picked a hell of a day to quit drinking. Thanks for that; I'll keep trying to digest what's happening, because I'm totally not grokking it.