dc655321
Major Contributor
- Joined
- Mar 4, 2018
- Messages
- 1,597
- Likes
- 2,235
That’s rather obvious isn’t it.. a digital volume control is never bit perfect .
If it were obvious to all we would not have threads like this one
That’s rather obvious isn’t it.. a digital volume control is never bit perfect .
The problem with the above implementation is the writing of the file. You're truncating the bits when writing out a 16 bit PCM file
The gain changes typically hit the exponent value.
I mentioned above that the checksum could only be maintained if gain is applied as a factor of two.
The weakest part in most playback chains is still the power amplifier. This is true even though there are some very good devices on the market today. The problem is even with an analogue volume control you cannot attenuate noise of this device. Most DACs have better figures than the power amplifiers. This means running the DAC right in front of the power amp there is no improvement by the analogue volume control at all.
So, you are all right in writing "... that it's already too loud at 10%, can't be good". I addressed it on the last page of my writing with:
"Another important point is that your power amplifier and your speakers should match. If the
perceived volume is inacceptable high running the amplifier without volume attenuation
either the amplifier is too strong for the speakers or the speakers are too sensitive for your amplifier."
Try this:If my 16 bit signal were a data file with a checksum or hash, and we go through DSP to change the volume, then somehow remove only the changes from the file that were related to the volume change, would the new 16 bit file pass the checksum or hash?
sox -V -b 16 -n test.wav synth 10 sin 3000 gain -1
sox: SoX v14.4.2
sox INFO nulfile: sample rate not specified; using 48000
Input File : '' (null)
Channels : 1
Sample Rate : 48000
Precision : 16-bit
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Output File : 'test.wav'
Channels : 1
Sample Rate : 48000
Precision : 16-bit
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'
sox INFO sox: effects chain: input 48000Hz 1 channels
sox INFO sox: effects chain: synth 48000Hz 1 channels
sox INFO sox: effects chain: gain 48000Hz 1 channels
sox INFO sox: effects chain: dither 48000Hz 1 channels
sox INFO sox: effects chain: output 48000Hz 1 channels
sox -V %1 -b 24 "%~dp1%~n1 truncate -33.wav" gain -33
sox -V %1 -b 24 "%~dp1%~n1 dither -33.wav" gain -33 dither
sox -V %1 -b 16 -D "%~dp1%~n1 +33.wav" gain 33
sox: SoX v14.4.2
sox INFO formats: detected file format type `wav'
sox INFO wav: EXTENSIBLE
Input File : 'E:\download\volume\test truncate -33.wav'
Channels : 1
Sample Rate : 48000
Precision : 24-bit
Duration : 00:00:10.00 = 480000 samples ~ 750 CDDA sectors
File Size : 1.44M
Bit Rate : 1.15M
Sample Encoding: 24-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
sox INFO sox: Overwriting `E:\download\volume\test truncate -33 +33.wav'
Output File : 'E:\download\volume\test truncate -33 +33.wav'
Channels : 1
Sample Rate : 48000
Precision : 16-bit
Duration : 00:00:10.00 = 480000 samples ~ 750 CDDA sectors
Sample Encoding: 16-bit Signed Integer PCM
Endian Type : little
Reverse Nibbles: no
Reverse Bits : no
Comment : 'Processed by SoX'
sox INFO sox: effects chain: input 48000Hz 1 channels
sox INFO sox: effects chain: gain 48000Hz 1 channels
sox INFO sox: effects chain: output 48000Hz 1 channels
MD5sums 1.2 freeware for Win9x/ME/NT/2000/XP+
Copyright (C) 2001-2005 Jem Berkes - http://www.pc-tools.net/
[Path] / filename MD5 sum
-------------------------------------------------------------------------------
[E:\download\volume\]
test dither -33.wav 8603b8d9a23585dbb7a67d362a9a1a55
test truncate -33 +33.wav 639fb1971da1ad3ccf1613090213bc26
test truncate -33.wav e84ddb9589c49a09b06b0356e28893d5
test.wav 639fb1971da1ad3ccf1613090213bc26
test dither -33 +33.wav 639fb1971da1ad3ccf1613090213bc26
BTW, MD5 is not a "secure" hash anymore,
That’s rather obvious isn’t it.. a digital volume control is never bit perfect .
Except at the max volume, right? (No attenuation.)
My previous reply has a test file. So everyone can try to convert the 32-bit float file to 24-bit integer file and examine the difference.Kind of a divergent topic, but what is your intuition on 25 bits for floating point? I believe that the IEEE spec is a 23 bit mantissa, 8 bit exponent, and 1 sign bit. That would simplistically give you 24 bits of precision when comparing to something like fixed point. I could possibly see how the lowest exponent bit could be considered an additional bit. Thoughts?
I doubt in the XMOS chip there is not enough memory to calculate a long enough (ron repeating) random sequence of numbers.
https://www.audiosciencereview.com/...table-field-recorder-review.15668/post-507610
Also this. So not only me. The authors of SoX also say 25 bits. For an apple to apple comparison in audio formats, it is the fact.
https://www.audiosciencereview.com/...depth-should-i-set-my-dac-to.8956/post-255104