FFAStrans forum

Hi
I have created a workflow, using AviSynth custom script and Audio Extraction processor whith following purpose:
1. take source WAV file containing 8 audio tracks
2. extract tracks 1,2 and 8
3. increase volume of track 8 by +3dB and add it to tracks 1 and 2
4. convert to stereo MP3 file

AviSynth script is as follows:

A1=GetChannel(m_clip, 1)
A2=GetChannel(m_clip, 2)
A8=GetChannel(m_clip, 8)
AD=AmplifydB(A8, 3)
Odd=MixAudio(A1, AD)
Even=MixAudio(A2, AD)
m_clip=MergeChannels(Odd, Even)
Return m_clip

If the size of source 8 track WAV file is above 2GB, then the operation in AviSnyth fails to create the audio file corectly: Odd audiotrack (A1) is correct, but Even audiotrack (A2) is incomplete (audio ends up earlier). See the screenshot from AudaCity attached.

To confirm that the issue is caussed by AviSynth I've set up the Audio Extraction processor into Stream Copy mode.

Any idea what is wrong?
Thanks,

Hey Silicon,
yeah wav and filesize are not the best friends... anyway interesting bug for ffms2 you found there. Not sure if the creator of ffms2 avisynth plugin ever added support for rf64 which would be the extension needed to come around the original wav size limit.

I just tried it and was able to confirm the behaviour that you describe, with one difference or better clarification: The second track is silent from a certain point but the first track is also not what it should be, it's crippled.

Anyway, ffmpeg seems to support wav's bigger than 2 GB, even when the rf64 extension is not used in the source file. So it should not be a problem to rewrap the original input wav file to mkv in order to come around the problems. Just do a commandline like
"%s_ffmpeg%" -i "%s_source%" -codec copy "%s_source%.mkv"
Make sure to check the "set s_source variable" box in the cmd processor and set it to %s_source%.mkv

It looked like the processing is also 5x faster when working with mkv instead of .wav input but maybe i mixed up something here...

Please let me know if this works for you!

@francebb you want to open a bug with the guys or shall we leave this as it is? Anyway, if you need it, here is a way to quickly create a test wav file:

I'm gonna try to reproduce it tomorrow.
Nice finding by the way.
To be fair I've never used FFAudioSource() with PCM files 'cause whenever I have a .wav I always use WAVSource() and I believe everyone in the Avisynth world uses it, which might be why nobody actually found out the bug.
I'll try to see if WAVSource() works and if it does and FFAudioSource() doesn't, then I'm gonna open a bug.
Myrsloik ain't gonna be happy, though xD

Hi FranceBB
If you have recomendation how to perform my task more effectivelly I'm happy to try. I'm AviAynth novice
Thanks

Hmmm from an efficiency perspective, it will always be better to avoid using avisynth. Basically using it will only be needed when you do heavy filtering/modifications on the picture - and of course it's a convenience thing because only this way you can use the majority of the inbuilt filter nodes in ffastrans.

Doing what you want with ffmpeg will dramatically speed up the processing.
In this example, i use the pan filter, which is not directly able to amplify the DB but it works with a "gain" value instead. I used 1.5 as the value above.

https://ffmpeg.org/ffmpeg-filters.html#pan-1

Hi @emcodem and @FranceBB
Thank both of you for proposed workarrounds. I have tested both of them and the winner is ... the one from FranceBB, sory emcodem .
FranceBB's workarround is easier and a little bit faster. Moreover emcodem's workarround creates a MP3 with lower volume form some reason.
Thanks again

Haha no worries, you know, we are all just interested in the scientifical truth here:D
Anyway, i am now discussing this with francebb and we both were not aware that the ffmpeg/avisynth integration could be that fast.

So the difference in "loudness" of the clips might just be the "gain value 1.5" i mentioned above, i am sure you can get the same result in both processings when playing with this value.

I tried using wavsource, which from ffastrans perspective means to generate an .avs file like that (other users, please note that when doing it this way, you don't have to use an A/V decode node anymore, but just use a text processor to generate the avs script and set it to be s_source)
Anyway, i did the speed test on commandline, here are the results when loading and wrinting to a local M2 drive:

Which means that the wavsource in avisynth is really fast AND the ffmpeg/avisynth integration is really good. But still at least on local M2 drive, the native ffmpeg filter and reader plugin was faster.

What was your results if i might ask?

Hi emcodem
As for the loudness your right of course: I have to play with gain values a little bit. When I reported it yesterday evening I have had an impression, that there is a volume difference between the files created by original AviSynth script but using differrent file wrappers at the input (WAV or MKV respectively), but I was wrong ... I have mismatched the test results

As for the speed - I have processed 3550 sec long WAV file:
- using AviSynth the overall workflow lasted 70 sec ("MP3 encoding" step lasted 49 sec) => overall speed 50x RT
- using custom FFmpeg the overall workflow lasted 54 sec ("MP3 encoding" step lasted 52 sec) => overall speed 65x RT

Ok perfect, so we are on the same page, thanks for re-testing. It is still a shame that working from NAS has such a big impact on the processing speed

emcodem wrote: ↑Thu Jul 22, 2021 9:20 am It is still a shame that working from NAS has such a big impact on the processing speed

said the one who sent me a sar.exe/cat.exe with 1-byte-read-access over the network for a 352 GB masterfile xD

(internal joke)


About the bug, here's what the developer of FFAudioSource() said:

I made BestAudioSource so I'd never have to look into audio bug reports for FFMS2 ever again. True story.

So it won't be fixed, but since there's WAVSource() it's not a big deal.
Out of curiosity, I also tried NICAudio() as audio indexer on those WAV files and it worked, so... since alternatives are in place, I guess this is pretty much it.