AviSynth behavior for redundant commands

[Wilbert]

Originally Posted by manolito

Bumping this thread because the global OPT_AllowFloatAudio=True command does not work as expected for me...

From the ALLOW I assumed that the audio output will be float only if the source filter delivers float samples. But instead the command seems to FORCE float audio no matter what.

I disabled all audio formats except 8bit int in the LAV Audio settings. The LAV status window correctly reports the input format as 32bit float aac and the output format as 8bit int PCM. But with the "global OPT_AllowFloatAudio=True" present in the AVS script the audio output from AviSynth is 32bit float.

This means that AviSynth actively converts 8bit int audio samples as delivered by the source filter to 32bit float - which of course does not make much sense.

Can anyone confirm this behavior?


Cheers
manolito

I think the magic happens in main.cpp. The relevant code:

          // Allow WAVE_FORMAT_IEEE_FLOAT audio output
          bool AllowFloatAudio = false;

          try {
            AVSValue v = env->GetVar("OPT_AllowFloatAudio");
            AllowFloatAudio = v.IsBool() ? v.AsBool() : false;
          }
          catch (IScriptEnvironment::NotFound) { }

          filter_graph = return_val.AsClip();

          if (!AllowFloatAudio && filter_graph->GetVideoInfo().IsSampleType(SAMPLE_FLOAT)) // Ensure samples are int     
            filter_graph = env->Invoke("ConvertAudioTo16bit", AVSValue(&return_val, 1)).AsClip();

          filter_graph = env->Invoke("Cache", AVSValue(filter_graph)).AsClip();

          filter_graph->SetCacheHints(CACHE_GENERIC, 999); // Give the top level cache a big head start!!

So if AllowFloatAudio is true, then the audio is passed through as it is. I can't explain what you are seeing

[sneaker_ger]

Set ConvertAudioTo8/16/24bit() and info() to absolutely make sure you really don't have float data.

[manolito]

Thanks guys

I had completely forgotten that the SSRC(48000) command in my script always converts audio to 32bit float.


Cheers
manolito

[manolito]

Bumping this thread because I found some interesting AviSynth peculiarities:

Originally Posted by manolito

Will "ConvertAudioTo24Bit()" do anything if audio already is 24bit?

The answer was NO, and this is correct. But for the same question if I change 24 to 32 then the answer has to be YES.

If my source is 32bit float and I use the command "ConvertAudioTo32Bit" then AviSynth will convert the audio to 32bit int.


Another item is the command "ConvertAudioToFloat()". The docs only say that the input gets converted to float, leading me to believe that the bit depth will not be altered. But in reality the command always converts any input to 32bit float, no matter what the source bit depth is.

Of course this makes sense, even though 16bit float and 24bit float are valid digital data formats, they are are just not used for digital audio samples. But I think that the AviSynth documentation should be clearer about this.


And finally something I have no explanation for:
Somehow I ended up with the following audio conversion:
32bit float -> 32bit int -> 32bit float
(using "ConvertAudioTo32Bit" and "ConvertAudioToFloat" on a 32bit float source)

A big waste of time, but IMO it should not hurt the audio. But this conversion changes the volume of the source up to 4dB depending on the source characteristics (the resulting volume will be lower). How in the world can this happen?


Cheers
manolito

[tebasuna51]

Originally Posted by manolito

The answer was NO, and this is correct. But for the same question if I change 24 to 32 then the answer has to be YES.

Of course, a 24 bits int sample is converted to a 32 bits int sample filling the 8 less significant bits with 0's. BTW you can recover the 24 bits without lose precission.

Take in mind than convert 24 to 16 bits int you lose the 8 less significant bits and can't be recovered.

Another item is the command "ConvertAudioToFloat()". The docs only say that the input gets converted to float, leading me to believe that the bit depth will not be altered. But in reality the command always converts any input to 32bit float, no matter what the source bit depth is.

Of course this makes sense, even though 16bit float and 24bit float are valid digital data formats, they are are just not used for digital audio samples. But I think that the AviSynth documentation should be clearer about this.

Yep. The docs must specify than the only float sample format supported by AviSynth is 32 bits float. The 16 and 24 float are not used for audio samples but 64 bits float is very used to avoid lose precision in arithmetic operations.

A 32 bits float sample have 8 bits for coeficient and 24 bits for mantissa, the precision is, more or less, the same than 24 bits int.

But this conversion changes the volume of the source up to 4dB depending on the source characteristics (the resulting volume will be lower). How in the world can this happen?

Float samples can have volume values over 0dB, when you convert to int samples all values over 0dB are truncated (audio clip).
All audio with float samples over 0dB must be Normalized before convert to int samples or encode.

[wonkey_monkey]

A 32 bits float sample have 8 bits for coeficient and 24 bits for mantissa

It's not an IEEE 754 float? No sign bit?

[Wilbert]

Originally Posted by davidhorman

It's not an IEEE 754 float? No sign bit?

Yes it is. See http://avisynth.nl/index.php/Float.

Yep. The docs must specify than the only float sample format supported by AviSynth is 32 bits float. The 16 and 24 float are not used for audio samples but 64 bits float is very used to avoid lose precision in arithmetic operations.

This is mentioned on several pages, but i will clarify it on the ConvertAudio page.

edit

Float samples can have volume values over 0dB, when you convert to int samples all values over 0dB are truncated (audio clip).

Are you sure about that? levels_max = 20 * log_{10} 1.0 = 0 dB. How can it have a volume larger than 0 dB (aside from rounding issues)?

[manolito]

Originally Posted by tebasuna51

Of course, a 24 bits int sample is converted to a 32 bits int sample filling the 8 less significant bits with 0's. BTW you can recover the 24 bits without lose precission.

Take in mind than convert 24 to 16 bits int you lose the 8 less significant bits and can't be recovered.

Sorry, I was not clear enough when I said "if I change 24 to 32". What I meant was:

Will "ConvertAudioTo32Bit()" do anything if audio already is 32bit?

If I convert a 32bit float source with "ConvertAudioTo32Bit" then this is not a NOP for AviSynth. Instead it will convert the 32bit float to 32bit int, and this is not lossless.



One other thing about the volume change when converting 32float to 32int and back to 32float:
When I analyzed the conversion result and compared it to the source, the RMS volume and also the BS1770 LUFS was a few dB lower than the source, but the sample peak level was the same in both cases (a slightly positive value). Strange...


Cheers
manolito

[manolito]

If someone is interested to reproduce my findings, I just uploaded a test archive with the relevant files (160MB):

http://www59.zippyshare.com/v/tAuCf3Cj/file.html

How I tested:
I used DirectShowSource with LAVFilters 0.65. In LAV audio I checked all output formats so LAV delivered 32bit float samples to AviSynth. The LAV mixer was disabled (no clipping protection active).

I used the following script:

global OPT_AllowFloatAudio=True
DirectshowSource("i:\test.mpg")
# ConvertAudioTo32Bit()
# ConvertAudioToFloat()

I used Wavi.exe to extract the WAV file from AviSynth. The first file "32.wav" was extracted with the above script, for the second file "32_2.wav" I activated the last two lines in the script.

The second file has an audible lower volume than the first one. I got the numbers from a Global Analysis in WaveLab.

Here are the pictures from WaveLab:



Note the positive peak values for the first file, and also the 3dB difference in the RMS value for the files.

Again my question: How can this happen? Converting from float to int might introduce clipping (if you don't normalize first), but it should not alter the volume.


Cheers
manolito