Skip to main content ↑ ↓
Topic: Wav volume changing FLAC sizes (Read 1254 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Wav volume changing FLAC sizes

My question is whether signal data is actually being created when raising the volume of a wav file.
I read this thread but still don't fully understand what is happening:
https://hydrogenaud.io/index.php/topic,113454.0.html
Basically, I acquired the MFSL SACD of the 1973 Lynyrd Skynyrd album. For portability reasons, I converted the dsf files to wav files via foobar. One of the options for this conversion in foobar is a volume increase of up to +6dB. The reason this exists is because (I've read) that the conversion from dsf (in this case dsd64) to wav lowers the volume quite a bit and this is there to adjust the volume back up with the caveat that you should check the outputted wav files to make sure they are not clipped (which I did in audacity).

I did this process twice, once with no volume modification (+0dB) and once with (+6dB). Then I encoded via flac -8 and noticed that file sizes of the +6dB file are bigger compared to the 0dB and that indeed more bitrate is being used to encode those files.

I don't understand what is happening unless actual encodeable signal is being created with a volume change...which is well...that can't happen...you can't create something from nothing right?

To me, it makes the the most sense to use the 0dB version and just use a replaygain tag to adjust the "volume up" (even though when played in foobar at the same volume settings as the corresponding .dsf file the 0dB file is most definitely quieter).

Re: Wav volume changing FLAC sizes

Reply #1 –
If you want to peak-normalize, then why not use the ReplayGain peak rather than the +6?

The SACD 1-bit signal is not a 16-bit PCM, so it cannot fit into a 16-bit .wav. Anything below is cut off, if you do not dither:
You will fill the 16 bits with "bits 1 to 16", and bit 1 is always zero and easily compressed away.
If you bump up the volume by 1 bit (approx 6 dB), then what was bit 1 is "clipped away" (which makes no difference since it was always zero) and what is fit into the .wav file is "bits 2 to 17".
So you take out the all-zero easily-compressible bit 1 and throw in the mostly-noise hardly-compressible-at-all bit 17. No wonder it gets larger.
High Voltage socket-nose-avatar

Re: Wav volume changing FLAC sizes

Reply #2 –
I'm not following what Porcus is saying, but at -6dB you're only using 15-bits.

You do loose resolution when you lower the volume digitally (with integer formats).   If you lower the volume in Audacity by 40-50dB, export-as 16-bits, open the file and re-boost the volume, you'll notice the loss of quality (quantization noise).

Quote
...to adjust the volume back up with the caveat that you should check the outputted wav files to make sure they are not clipped (which I did in audacity).
A better approach might be to create a 24-bit WAV, open in Audacity and amplify or normalize, then export to 16-bit FLAC.  That way you wouldn't have to guess the gain/amplification setting.

Re: Wav volume changing FLAC sizes

Reply #3 –
Quote from: DVDdoug on
I'm not following what Porcus is saying, but at -6dB you're only using 15-bits.  


Thanks for the response Okay, I was confused by porcus as well because these were all 24bit 88.2 wav files...not 16 bit.

With that said, I understand what you're saying about going down in volume and losing a bit of data therefore the bitrate could be lower. But what I'm explaining is the exact opposite as the "starting track" is at 0dB and the "other" track is at +6dB but generated from the 0dB track. So if you increase the volume, in this case +6dB are you adding encodable info that FLAC would use? Where does it come from. That's where I am confused.

Re: Wav volume changing FLAC sizes

Reply #4 –
Quote
But if you increase the volume, so +6dB are you adding encodable info that FLAC would use?
If you start with a 16-bit FLAC or WAV, no.   Boosting the volume doesn't add information.*   If you start with a higher-resolution file, yes.  You are saving more information.

However, if you use Audacity it will dither by default.   Dither is added noise so it will make a bigger FLAC. 




* There could be some rounding and that might cause an "apparent" increase in resolution...  I'm not sure...

Re: Wav volume changing FLAC sizes

Reply #5 –
If you multiply by an exact multiple of 2 and then don't dither then the file size may remain the same. Otherwise it should increase.

Re: Wav volume changing FLAC sizes

Reply #6 –
Quote from: DVDdoug on
A better approach might be to create a 24-bit WAV, open in Audacity and amplify or normalize, then export to 16-bit FLAC.  That way you wouldn't have to guess the gain/amplification setting.
That's a good idea...the not having to guess about the gain part. The 24bit wav is what what I've been doing already. However since the 0dB outputted file is smaller anyway I think I'll stick with it and use a replaygain tag.

What I don't know is if the foo_input_sacd component creates a pcm file and then changes it's amplitude after the fact (like what I would be doing using Audacity), or if that +6dB option actually happens during the conversion itself thus making the 0dB and 6dB files actually different. Then it would make a difference whether to use it or not.

Re: Wav volume changing FLAC sizes

Reply #7 –
I did an experiment in Audacity- Interesting results...

Original 0dB-normalized FLAC = 20,571 KB
-6dB FLAC = 18,648 KB
Re-boosted FLAC with default dither = 20,769 KB
Re-boosted FLAC with no dither = 20,667 KB

There was some "funny" rounding because when I re-boosted, Audacity would only allow me to boost by 5.999dB (unless I allowed clipping) so I boosted by 5.999.

And, I think  6dB is not an exact factor of two...   The calculator says it's not, but I don't know how much precision the calculator gives me with logs...  
 

Re: Wav volume changing FLAC sizes

Reply #8 –
Quote from: DVDdoug on
And, I think  6dB is not an exact factor of two...   The calculator says it's not, but I don't know how much precision the calculator gives me with logs...  

20*log10(2) = 6.02059991

If you want to do bit exact adjustments though you shouldn't be using floating point values at all as they are intrinsically approximate. 

Re: Wav volume changing FLAC sizes

Reply #9 –
32 bit float can exactly represent any 16 bit or 24 bit integer.

Re: Wav volume changing FLAC sizes

Reply #10 –
Quote from: pdq on
32 bit float can exactly represent any 16 bit or 24 bit integer.

But not the logarithm base 10 of any integer, which is the problem here. 

Re: Wav volume changing FLAC sizes

Reply #11 –
Quote from: saratoga on
Quote from: pdq on
32 bit float can exactly represent any 16 bit or 24 bit integer.

But not the logarithm base 10 of any integer, which is the problem here. 
Neither one can do that losslessly. So what?

The point is that working in float (let alone double) retains greater precision than 16 or 24 bit integer.

Re: Wav volume changing FLAC sizes

Reply #12 –
Quote from: pdq on
Quote from: saratoga on
Quote from: pdq on
32 bit float can exactly represent any 16 bit or 24 bit integer.

But not the logarithm base 10 of any integer, which is the problem here. 
Neither one can do that losslessly. So what?

If the gain is specified as an integer value rather than as the log of a floating point value, it can be applied exactly in this case.

Re: Wav volume changing FLAC sizes

Reply #13 –
Nothing is perfect, FLAC predictors aren't either. There surely exist data patterns that you can add to sound file, which don't add actual meaningful information, but will cause FLAC files to bloat because its predictors won't handle them efficiently. FLAC isn't a format that aims at maximum compression.

Re: Wav volume changing FLAC sizes

Reply #14 –
Quote from: rutra80 on
Nothing is perfect, FLAC predictors aren't either. There surely exist data patterns that you can add to sound file, which don't add actual meaningful information, but will cause FLAC files to bloat because its predictors won't handle them efficiently. FLAC isn't a format that aims at maximum compression.

You can add predictors which might decrease the file size a little.  Here is one set that I have used:
--best -e -A "tukey(0.67)" -A "partial_tukey(10/0.33/0.22)" -A "punchout_tukey(10/0.33/0.22)" -A "blackman_harris_4term_92db" -A "gauss(0.005)" -A "partial_tukey(3/0.50/0.33)" -A "punchout_tukey(4/0.50/0.33)"

Re: Wav volume changing FLAC sizes

Reply #15 –
If there's no clipping then the louder version is effectively having +1 more bit depth.
+6 dB is roughly 1 more bit if you're using linear PCM sampling. 
It's "useful" in a sense that theoretical S/N ratio is +6 dB more, but nobody will be able to hear the difference likely.

Also if you multiply an already integer wave by exactly 2 so that the lowest bit is always zero (and you aren't adding quantization distortion nor any new information), FLAC will see this and compress just as well.
Keep calm and opusenc --bitrate 128

Re: Wav volume changing FLAC sizes

Reply #16 –
Quote from: magicgoose on
If there's no clipping then the louder version is effectively having +1 more bit depth.
+6 dB is roughly 1 more bit if you're using linear PCM sampling. 
It's "useful" in a sense that theoretical S/N ratio is +6 dB more, but nobody will be able to hear the difference likely.

So if I don't increase the volume by the 6dB, I'm potentially only using 15 versus 16 bits...which only really has an effect if I turn the volume way up and ?maybe? I'll hear a slight hiss before I would with the +6dB version...but most likely not?

I think I'll keep the straight converted files as they make smaller FLAC (and MP3) files and with replay-gain sound just as loud. They tend to hover around 86-87dB anyway which is very close to the FLAC replay-gain standard if 89dB.

Re: Wav volume changing FLAC sizes

Reply #17 –
Yes, if your files are quieter than could be possible without clipping, and they are stored in integer format, then you are effectively using less than X bits per sample where X is the actual bit depth of the file; because highest values aren't being used for coding.

Yes it's about a little bit more hiss (or distortion, depends on the rounding method). Can't say for all variants of this and all music genres, but there is a big chance that everything will be OK.
Keep calm and opusenc --bitrate 128
 
SimplePortal 1.0.0 RC1 © 2008-2019