AviSynth Trim/Splice dropping audio

[an3k]

I have this scriptSetMemoryMax(512)
SetMTMode(3)

LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindexnv\DGDecodeNV.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\NicAudio.dll")

PT1_v = DGSource("E:\LOTR1_PT1\00000.track_4113.dgi",fieldop=0).Crop(0,140,0,-140).ConvertToYV12()
PT1_a = RaWavSource("E:\LOTR1_PT1\00000.track_4352.w64", 4)

PT2_v = DGSource("E:\LOTR1_PT2\00013.track_4113.dgi",fieldop=0).Crop(0,140,0,-140).ConvertToYV12()
PT2_a = RaWavSource("E:\LOTR1_PT2\00013.track_4352.w64", 4)

SetMTMode(2)

PT1 = AudioDub(PT1_v,PT1_a).Trim(0,151968)

PT2 = AudioDub(PT2_v,PT2_a).Trim(48,0)

SEE = UnalignedSplice(PT1,PT2)

return SEE

The above script is for the english audio. I also have one for the german one (slightly different filenames).
The result for the english audio is that AviSynth removes the original audio and inserts silence beginning at ~2:37:10.843 until the end so starting somewhere in the middle of PT2.
The result for the german audio is that there is silence until 1:45:38.331 (= the whole PT1 is silent) and then the whole PT2 is fine.

I also have tried AlignedSplice and got different results (but still missing audio). I also tried Trim(x,x,false) but that just removed the parts that were silent in the above encodes from the resulting files.

I manually checked the source w64 files in WMP12 and Audacity and there is audio from the beginning to the end and the length are fine too.

The w64 sources were re-encoded from DTS-HD Master with eac3to and in AviSynth (MeGUI) I've chosen FLAC as output and NicAudio as Decoder.

Any help is much appreciated!

[an3k]

Found the problem: NicAudio

English audio:

TOP LEFT: RaWavSource("E:\LOTR1_PT1\00000.track_4352.w64", 4)
TOP RIGHT: RaWavSource("E:\LOTR1_PT2\00013.track_4352.w64", 4)
BOTTOM LEFT: LWLibavAudioSource("E:\LOTR1_PT1\00000.track_4352.w64",cache=false)
BOTTOM RIGHT: LWLibavAudioSource("E:\LOTR1_PT2\00013.track_4352.w64")

E:\LOTR1_PT1\00000.track_4352.w64 = 6.393.074.816 Bytes
E:\LOTR1_PT2\00013.track_4352.w64 = 7.414.192.256 Bytes
http://i.imgur.com/pKvRCHC.png

German audio:

TOP LEFT: RaWavSource("E:\LOTR1_PT1\00000.track_4353.w64", 4)
TOP RIGHT: RaWavSource("E:\LOTR1_PT2\00013.track_4353.w64", 4)
BOTTOM LEFT: LWLibavAudioSource("E:\LOTR1_PT1\00000.track_4353.w64")
BOTTOM RIGHT: LWLibavAudioSource("E:\LOTR1_PT2\00013.track_4353.w64")

E:\LOTR1_PT1\00000.track_4353.w64 = 4.262.049.920 Bytes
E:\LOTR1_PT2\00013.track_4353.w64 = 4.942.794.880 Bytes
http://i.imgur.com/mxZYskL.png

I had to disable cache for the english PT1 audio because L-SMASH wasn't able to successfully create an index file. It went over ~202 MB then restarted at 0 MB and finally crashed at ~150 MB. No errors for the other WAVE64 files.

[StainlessS]

Have you tried trim video before dub audio. (Then perhaps delayaudio)

Edit, oops looks like you already solved problem.

Mobile:

[an3k]

Have you tried trim video before dub audio. (Then perhaps delayaudio)

Edit, oops looks like you already solved problem.Yeah however thanks for your input :)

I just encoded both (eng / ger) and there are no problems anymore.

Because I had some audio using NicAudio but just "some" sample drops I didn't thought that NicAudio could be the problem but my source files or avisynth script. After everything failed I tried a different Source Filter.

Regarding your suggestions: I understand how delaying would work for PT2 (DelayAudio(-2.002)) but not for PT1. Do I miss something? I have to cut off the end of PT1 and the beginning of PT2.

[StainlessS]

I think tebasuna51 did a mod of NicAudio about 1.5 - 2 years ago (some kind of problem fix), if you have not updated in that time period.

Regarding your suggestions: I understand how delaying would work for PT2 (DelayAudio(-2.002)) but not for PT1. Do I miss something? I have to cut off the end of PT1 and the beginning of PT2.

I'm not feelin' too chippa today (feelin a bit delicate) so I will pass on above [my brain just dont wanna work at all].

EDIT: Maybe I'll go back to bed for a week or two.

[tebasuna51]

When a AviSynth audio decoder open a audio file must inform to AviSynth about this (and only this) four audio properties:

Info.nchannels
Info.sample_type
Info.audio_samples_per_second
Info.num_audio_samples (total Audio length)

After that is AviSynth than manage this data to trim (or othe audio operations).
All properties seems ok except the trimed Audio length in 2 audio files (the other 2 seems ok):

RaWavSource("E:\LOTR1_PT2\00013.track_4352.w64", 4)
Trimed Audio Length: 148 534 516 (correct value must be 353 056 768)

RaWavSource("E:\LOTR1_PT1\00000.track_4353.w64", 4)
Trimed Audio Length: 18 446 744 073 707 200 368 (absurd value, correct value must be 304 432 128)

I can't understand what hapens in this 2 files, when work correctly with the other 2 files with same Trimed Audio length.
Just for curiosity, what AviSynth version are you using?

BTW, I consider NicAudio (and BassAudio) deprecated, and I recommend use always LWLibavAudioSource like AviSynth audio decoder, like I say already in MeGUI thread.

[Wilbert]

What happens if you don't trim? Does RaWavSource load them fine?
RaWavSource("E:\LOTR1_PT1\00000.track_4353.w64", 4)

What does the argument value 4 mean? The syntax of the filter is

env->AddFunction("RaWavSource", "s[samplerate]i[samplebits]i[channels]i", m2RaWavSource::Create, 0);

[an3k]

What happens if you don't trim? Does RaWavSource load them fine?
RaWavSource("E:\LOTR1_PT1\00000.track_4353.w64", 4)
Haven't tried yet, will do after the current encode has finished. I'll also try if manually specifying SampleRate, SampleBits and Channels would help.
What does the argument value 4 mean? The syntax of the filter is

env->AddFunction("RaWavSource", "s[samplerate]i[samplebits]i[channels]i", m2RaWavSource::Create, 0);
Taken from the official homepage (https://nicaudio.codeplex.com/) / avisynth.nl documentation (http://avisynth.nl/index.php/NicAudio):"SampleRate" Necessary for lpcm and raw files. In RaWavSource a value < 9 means a header with valid
values for SampleRate/SampleBits/Channels and now means:
IgnoreLength 1 force ignore the data size read in the header also in 64 bits formats.
2 ignore the data size 32 bits read in the header if > 2GB. (default)
4 ignore the data size 32 bits read in the header if > 4GB.

[an3k]

What happens if you don't trim? Does RaWavSource load them fine?
RaWavSource("E:\LOTR1_PT1\00000.track_4353.w64", 4)
Even then the files are not loaded correctly. The very same values are shown as with trimming (because Info() comes before Trim() in the AviSynth script).

Manually specifying SampleRate, SampleBits and Channels solved the problem (length of all four (eng/ger PT1/PT2) are correct now). However now both English parts are shown with 6 samples more than when using L-SMASH works (eg. now 304432134 / previously 304432128) and both German parts are shown with 9 samples more (eg. now 353056777 / previously 353056768). But I don't know if this would be a problem.

[tebasuna51]

What happens if you don't trim? Does RaWavSource load them fine?
I tested many w64 files without problems.

BTW the NicAudio.dll is compiled with a avisynth.h from v2.5.8 and is not compliant with IanB recomendations for 2.60 plugins.
Even I don't know if can be used in AviSynth MT mode.

What does the argument value 4 mean?
With a w64 file this value is ignored. We only need:
RaWavSource("input.w64")

Only RaWavSource("input.w64", 1) means force ignore the data size read in the header, then the (filesize - header_length) is used as audio data size.
Only usefull when know than data size in header is corrupt.

EDIT:
For instance the file E:\LOTR1_PT2\00013.track_4352.w64 = 7.414.192.256 Bytes, loaded with:
RaWavSource("E:\LOTR1_PT2\00013.track_4352.w64", 1)

must show a duration of (21 is 7 channels x 3 bytes per sample):
(7.414.192.256 -128) / 21 / 48000 = 7355,34933... exactly 2:02:35.349 like show LWLibavAudioSource

[tebasuna51]

The w64 sources were re-encoded from DTS-HD Master with eac3to
Correct.

and in AviSynth (MeGUI) I've chosen FLAC as output and NicAudio as Decoder.

Wrong, NicAudio don't support DTS-HD and the output can be corrupt.

[kuchikirukia]

I've had a lot of problems with eac3to converting DTS-MA to wav/wav64. That "cut off at 51 minutes" is familiar. It'll also turn 2 hours into 10 and be garbage to boot.
It doesn't have these problems converting to DTS-MA to FLAC.

[tebasuna51]

I've had a lot of problems with eac3to converting DTS-MA to wav/wav64. That "cut off at 51 minutes" is familiar. It'll also turn 2 hours into 10 and be garbage to boot.

I never see that problem with W64 files because have fields 64_int to store values greater than 4 GB in Data_Size and File_length.

Of course if you use WAV files with header fields 32_int the max value than can be stored is 4 GB.

eac3to can make WAV's greater than 4 GB, with wrong values in Data_Size and File_length header fields, then some soft can ignore data beyond the 4GB, even some soft than read the 32_int like signed have problems beyond 2 GB.

For that many encoders have parameters to ignore the Data_size in header and force encode to end of file. For instance the FLAC v1.2 parameter --ignore-chunk-sizes

Talking about AviSynth we can't expect problems because AviSynth.h I use (2012/01/18) for NicAudio.dll have:

int audio_samples_per_second; // 0 means no audio
int sample_type; // as of 2.5
__int64 num_audio_samples; // changed as of 2.5
int nchannels; // as of 2.5

And the num_audio_samples use already 64 int values.

[tebasuna51]

Even then the files are not loaded correctly. The very same values are shown as with trimming (because Info() comes before Trim() in the AviSynth script).

Don't have sense for me.
LWLibavAudioSource RaWavSource
W64 file Size in bytes correct samples samples
---------------- ------------- ------------------ -----------
00000.track_4352 6.393.074.816 304.432.128 304.432.128
00013.track_4352 7.414.192.256 353.056.768 * 148.534.516
00000.track_4353 4.262.049.920 304.432.128 * 18.446.744.073.707.200.368
00013.track_4353 4.942.794.880 353.056.768 353.056.768

* For what these 2 files are loaded incorrectly by RaWavSource, when the other 2 files with the same num of samples are loaded ok?

Manually specifying SampleRate, SampleBits and Channels solved the problem (length of all four (eng/ger PT1/PT2) are correct now). However now both English parts are shown with 6 samples more than when using L-SMASH works (eg. now 304432134 / previously 304432128) and both German parts are shown with 9 samples more (eg. now 353056777 / previously 353056768). But I don't know if this would be a problem.

Then the data are considered like raw PCM samples and the header (128 bytes) are treated also like PCM samples.

Like 128 is not a multiple of 21 (7 channels x 3 bytes for sample English) or 14 (7 channels x 2 bytes for sample German) all data are missaligned and the output is garbage.