,6Upsampleing

16 to 24 bits

- N 5.0.2 build 2205 -

recently downloaded an application that shows how many bits a track/sample was recorded at -

loaded in 16 bit track - showed 16 bits -
loaded in 24 bit track - showed 24 bits - i downloaded some
24bit tracks from the net for this test -

OK so far -

loaded 16 bit track back in, did mixdown selecting the save as 24bit option -

loaded 24 bit version of 16 bit track back in - still showed 16bits - TRACK PROPERTIES said it was a 24 bit track -

sent note to Flavio who replied

"If the track’s original signal was recorded at 16 bits the real resolution of the file will still be 16 bits even after you convert it to 24 bits. The information that was lost in the sampling of the analog signal is lost forever and can’t be recovered in the 16 to 24 bit conversion. It’s just like when you take a low resolution image and convert it to an high resolution, for example if you take a 640x480 photograph and you convert it to 6400x4800 it will still appear to have a low resolution" -

OK

did exactly the same in SONAR LE - loaded in 16 bit file, saved as 24 bit file, Sonar returned a 24 bit file - further proof that this was so is that the track size had increases by a third -
(16 to 32 size would have doubled, 16 to 24 1/3rd is correct) -

checked then if N was actually recording at 24 bits, YES ALL OK -

it looks like, if anybody has for whatever reason taken a 16 bit track in N and tried to save it as a 24 bit track thinking that somehow it may increase the track quality, then that track is still at 16 bits regardless of what the track property says -

the application is BITVIEWER (part of the VST utility bag)
available from link below -

http://www.tobybear.de/p_utilbag.html -

Dr J

N track seems to be able to run 16bit and 24 bit wavs in a same song so there’s no need for upscaling the 16 bit files.

The only thing ‘upsampling’ 16 to 24 upon loading the track can possibly do is pad the extra digits with zeroes anyway. No point in doing it. Since the internal audio/mix engine runs at 32 (or 64) bits, you can effect the 16 bit track with plugins and not degrade the audio.

D

Try it again but dither.

I’m surprised the app said it was a 16 bit track. Does the app just look at the WAV properties, or actually scan the track looking at significant bits? If the latter, good: n-Track was doing the right thing, and SONAR LE was not (or you have dithering turned on). It must be the latter, based on my experience with n-Track.

If you have dBPowerAmp Music Converter installed (as any tracker should – especially if you collaborate via internet), hover the mouse over the track & tell us what it says about the format. It gives lots of info, but all based only on the WAV hearder (or whatever format header).

BTW, I’ve read a lot of discussions where they say that for a well-recorded track, nobody can hear the difference between a 16-bit track and a 24-bit one. But good listeners can hear the difference between a MIX made from 16-bit and 24-bit tracks.

My theory is that the problem is the quantization noise in the 16-bit tracks, and if they were all dithered before mixing, the results would be better. This shouldn’t be surprising. I worked in medical imaging, where it was standard practice to dither images BEFORE processing to avoid really nasty visual artifacts. The hardware even did this (just as, with a 24-bit card, we really only get 20 significant bits and the low order 4 are random).

I’d love to put my hypothesis to the test some time!