WAVSource() cannot index files larger than 4 GB
FranceBB opened this issue · 4 comments
Hi there,
using WAVSource() with files larger than 4GB and opening the AVS Script in FFMpeg makes it fail to load.
It works with BestAudioSource(), though.
How to reproduce:
Create an AVS Script like so:
p1=ColorBars(848, 480, pixel_type="YV24")
p2=ColorBars(848, 480, pixel_type="YV24")
p1++p2
ch1=GetChannel(1)
ch2=GetChannel(2)
MergeChannels(ch1, ch2, ch1, ch2, ch1, ch2, ch1, ch2, ch1, ch2, ch1, ch2, ch1, ch2, ch1, ch2)
load it with VirtualDub and export it as .wav
it will create a 10.5 GB, 16ch .wav file.
Now create a new AVS Script and try to index the audio with WAVSource(). It will fail.
This issue should really be addressed in Avisynth+ as .wav files larger than 4 GB are much more common in 2022 than they were in early 2000...
A few things to note. When saving audio, VDub2 defaults to "Windows audio (*.wav, *.w64)" and it automatically saves to wave64 after 2gb. Smaller files are saved as a wav. You can override this behavior and choose "Windows audio (*.wav)", however, bigger files do not play correctly. I saved a 5 hour wav this way and mpc-hc only plays about 1.5 hours. I also loaded this wav file in Sony Sound Forge and encountered the same problem.
WavSource is unable to read Wave64 files, regardless of size.
The wav size problem has been mentioned to previous devs and both mentioned VFW limitation: Shodan and IanB
On the bright side, DirectShowSource is able to open Wave64 files without a problem.
What happens if you try using OpenDMLSource or AVIFileSource instead of WavSource? Even though the docs say that it tries to default to using the OpenDML handler when using AVISource, you might want to be explicit.
WavSource can/maybe be considered an alias of the other ones, although perhaps just for audio. But if it skips the OpenDML preference logic, you might end up hitting a wall where using AVISource/OpenDMLSource/AVIFileSource wouldn't.
Although I still think it might have bugs just due to the note above about it being a VFW limitation.
To be completely honest, I think it might be worth considering having a raw video and PCM audio decoder included in the AviSynth+ core, since the RIFF format itself is rather simple, and then it can just skip trying to use VFW at all. The bonus of that is it could also be used on the other OSes as well. Not that I could write that, just putting the idea out there (and not relying on something like libavcodec either, that would defeat the purpose of raw decoders being there strictly for simple cases). The point of it being in the core itself is so that other demuxing source filters could just call up the decoders if it happens to be uncompressed video or audio.
What happens if you try using OpenDMLSource or AVIFileSource instead of WavSource?
I tried with just a normal wav file, 600mb.
OpenDMLSource:
File open error
---------------------------
Avisynth open failure:
Invalid AVI file: RIFF type is not 'AVI'
AVIFileSource:
File open error
---------------------------
Avisynth open failure:
AviSource: Could not locate video stream.
Yeah, well, right now I've committed an emergency fix to the supply chain I have at work to use BestAudioSource(), however it would really be nice to have RIFF support in the core, so I totally second the idea of having it to replace the whole VFW thing (and the fact that it would be cross-platform is great as my dream one day is to replace all the windows server with Linux distros). If someone wants to pick up the thing and do it, be my guest. :)
If a bounty is needed, I can ask my colleagues and we might come up with something to reward whoever would like to do it. :)