Larger than 2GB WAV source files?

[karl_lillevold]

I have been using Avisynth with 6ch WAV files as input for the new multi-channel support in Helix Producer (http://forum.doom9.org/showthread.php?s=&threadid=56684), but until now just short samples. For longer samples, the 6ch WAV files tend to get rather large. It looks like there is a problem reading large WAV files, I am guessing around 2GB or so ("AVIFileSource : couldn't open file"). Helix Producer can not read the WAV file either, when used as a separate input, so either there is a problem in both Avisynth and Helix Producer, or Besweet produces a problematic WAV file. I have tried a couple of examples, both with the same problem. Cool Edit Pro seems to be able to open the large WAV file so the problem appears to lie in Avisynth (and Producer).

Advice? work-arounds? other methods?

[sh0dan]

****** - It seems to use the old non-OpenDML method of opening and parsing the wav-files. It does however not support >2GB files.

I'm not sure if there is an easy fix for this. I'll have a look at it ASAP - for now I've added it to the Sourceforge tracker. Updates should be posted there.

[karl_lillevold]

Okay, thanks. I am looking forward to a fix in Avisynth. In the meantime, the only option in Producer is to use the method of separate audio and video inputs, audio being an AC3 track decoded on the fly to producer by ac3filter, video an Avisynth script.

[I read the sh0dan's original post before it was edited] ;) ******, is what I thought too, when I first discovered Producer had this problem for standalone WAVs, then thinking this must not be a problem when the WAV is coming via Avisynth, only to discover it was. Glad it's been found though, I did not find any problem reports on this topic here or in the Q&A section of Avisynth.

[Wilbert]

Maybe it's of no use ... But you could also make six separate waves with Besweet, import them in AviSynth and use MergeChannels (http://www.avisynth.org/index.php?page=MergeChannels) to make a 5.1 WAV. The channel ordening should be like this (http://www.avisynth.org/index.php?page=GetChannel).

[sh0dan]

@Wilbert: Actually I'm not sure it's correct - I have been putting together several WAV's to a single 6ch wave to be encoded by BeSweet. In my experience the order is:

Left, Center, Rigth, Rear Left, Rear Right, LFE.

AC3filter seems to confirm this. Are you sure the docs are right?

@Karl: Yeah - sometimes it's nice to have Donald as my extended super-ego :)

[Wilbert]

Yes, you are right. I will correct the docs.

[karl_lillevold]

I got it to work with separate waves, but the channel mapping is confusing, what I found does not match either the docs or sh0dan's suggestion:

AuFL =WAVSource("ac3test-FL.wav")
AuFR =WAVSource("ac3test-FR.wav")
AuC =WAVSource("ac3test-C.wav")
AuLFE=WAVSource("ac3test-LFE.wav")
AuSL =WAVSource("ac3test-SL.wav")
AuSR =WAVSource("ac3test-SR.wav")

Audio=MergeChannels(AuFL,AuFR,AuC,AuLFE,AuSL,AuSR)

So : Front Left, Front Right, Center, LFE, Rear Left, Rear Right

EDIT: 07/14/03: swapped Rear channels

[Wilbert]

I guess the channels are stored in a different order as in AC3, have to ask DSPGuru about that :) At hydrogenaudio.org we were told that the ordening in AAC is different from AC3 or 5.1 WAV.

This should be the ordening: WAVE-FORMAT-EXTENSIBLE (http://www.cs.bath.ac.uk/~jpff/NOS-DREAM/researchdev/wave-ex/wave_ex.html) of a true 5.1 WAV.

[DeXT]

That's right, every file format has a different channel order. The right one for 5.1 WAV is the one posted by Karl (as seen in this (http://www.microsoft.com/whdc/hwdev/tech/audio/multichaud.mspx) doc from microsoft), and a multichannel soundcard is expected to do the mapping to the speakers from this one.

The order posted by sh0dan is the one used for AC3, and should not be used for WAV (any tool doing a conversion to WAV should remap the channels to the right positions). Thanks God (or thanks DSPGuru ;) ) BeSweet does the needed remapping when using -6chwav output.

AAC also uses a different channel order (as posted by Ivan here (http://www.hydrogenaudio.org/index.php?showtopic=10986)) but neither faac, Nero or Psytel do the needed channel remapping when encoding, so they basically have to be fed with WAV files using a 'custom' channel order to do a proper multichannel encoding. Menno added channel remapping in his latest faad2 cvs update when decoding from AAC to WAV, but faac isn't updated yet. CoreAAC has to be fixed, too. So we are currently on the middle of the road here.

[sh0dan]

Utterly stupid! :rolleyes:

Glad AviSynth doesn't assume any channel order - that way it's just none of our problem. ;)

Anyway - I'm also looking a bit at AC3Filter, for loading AC3 material. It seems like a very good start -I just don't know if seeking will be possible.

[Nic]

OT: I was going to go back and rewrite AC3 and MPA source filter very soon, but coming from a MPEG input rather than raw file....makes seeking even harder :( But im going to use a d2v file as an input, so maybe I could make use of the offsets in there, but audio sync is a problem (ill put audio sync code in there to find the initial delay of the file, but not sure if it will work so well in the middle of a file :( )

And your right the whole channel mapping thing is stupid. But I didn't know all that. Thanks Dext :)

-Nic

[Wilbert]

@DeXT,

Do you know how the channels are ordered in AIFF and DTS?

[DeXT]

According to the AIFF specification (http://preserve.harvard.edu/standards/Audio%20IFF%20Specification%201%203.pdf) the channel order for 5.1 should be as follows: Left, LeftCenter, Center, Right, RightCenter, Surround. These channel labels are pretty old (it's back from 1988!) and I'm not sure how they correlate with the current 5.1 setup.

About DTS, I guess it all depends on the decoder (in case it does the remap or not) but the default channel arrangement can be found in the specs (http://webapp.etsi.org/action%5CPU/20020827/ts_102114v010101p.pdf). It seems it's Center, Left, Right, SurroundLeft, SurroundRight for a 5ch setup, and the LFE is on a separate stream (much like on multichannel MPEG2).

[karl_lillevold]

The fact that > 2 GB WAV files created by HeadAC3he worked as input to Avisynth was confusing, so I did a little more searching.

Here is what riffwalk outputs for the Besweet created wave:

00000000 RIFF (FFFFFFF7) 'WAVE'
00000000
warning: RIFF file contains 4E20 additional bytes after end of RIFF chunk.
00004E20

while for the HeadAC3he file, it looks like:

00000000 RIFF (E384A024) 'WAVE'
0000000C fmt (00000010)
wFormatTag : WAVE_FORMAT_PCM
nChannels : 6
nSamplesPerSec : 48000
nAvgBytesPerSec : 576000
nBlockAlign : 12
nBitsPerSample : 16
00000024 data (E384A000)
warning: 'RIFF' chunk at offset 0 ends at offset E384A02C -- should be 4E20
FFFFFFFF


The HeadAC3he version looks much more correct, so I went over to the Audio encoding forum and searched for Besweet and 2GB (http://forum.doom9.org/showthread.php?s=&postid=305084&highlight=2gb#post305084). As you can see, it looks like Besweet has a 2GB barrier, and since >2GB HeadAC3he created WAV files work fine as input to Avisynth, maybe Avisynth does not have a 2GB problem after all..

[sh0dan]

ok - so you are able to load the HeadAC3 WAV?

Anyway - I've begun implementing DirectShow audio input, and have just made pure audio working. It should be able to import AC3 and large WAV-files at some stage. There are still some DirectShow quirks that needs to be sorted out, but the initial impression is good.

Furthermore I just made ResampleAudio work on any number of channels - so sound support is getting better.

[karl_lillevold]

Yes, waves from headac3 seem to work, but there is still some weirdness. When encoding the avs in producer it appears to get sound all the way through, but when I play the avs file in MPC, I get sound only until the 2GB point in the WAV file at 1hr3min or so. Note that for this MPC playback test I have to use GetChannel/MergeChannels to extract just two channels, because for some reason it is not possible to play a 5.1 WAVEXT file in WinXP.

I am looking forward to trying out DirectShowSource for audio when it is ready.