Delaycut questions

[spiritgumm]

I've read elsewhere that if an ac3 file name has a delay in it (such as when demuxed thru DGindex), then Delaycut will use that number automatically when loaded. True? If yes, then would inputting to the Delay START box add even more delay, or does one delay take precedence over the other?

How can you visually doublecheck that the fixed file is really fixed? I thought the info in the INFO window would be different between the original and fixed files, but when I load both, they are the same. I am only using small delays (under 20 ms). I can see from testing that large delays will make the fixed file info different than the original.

[V1de0Luvr]

Delaycut will indeed patch an audio file to what DGindex has tagged it during demuxing. I have used it for exactly that, but do not know the answer to your other question.

[manono]

I've read elsewhere that if an ac3 file name has a delay in it (such as when demuxed thru DGindex), then Delaycut will use that number automatically when loaded. True?

No.

How can you visually doublecheck that the fixed file is really fixed?

Well, unless you make it stay the original length, then the before and after sizes will be slightly different. If you do keep them the same length by adding or cutting from the end, then check the log.

[spiritgumm]

I didn't tick "original length" but the duration before/after looks the same. Apparently there's a minimum 16 ms delay required before a change is reflected in INFO. Does that mean anything less is ignored, or just isn't reflected in the INFO?

As a test, I also increased the delay number in the filename (to 800 ms), and processed that without manually adding a delay. There was no change between duration before/after, so manono is correct, a filename with delay won't automatically set Delaycut. I read elsewhere it would in "CLI" (command line mode?), but I don't know about that.

Here's a typical filename from DGindex:
VTS_01_1 T80 2_0ch 192Kbps DELAY 8ms.ac3

If I enter the delay manually, as shown in pic, the input and target info look the same. After processing, if I reopen Delaycut and load either original or fixed audio, their Input info looks the same, likes there's no change.


LOG
[Input info]
Bitrate=192
Actual rate=192.000000
Sampling Frec=48000
TotalFrames=88606
Bytesperframe= 768.0000
Filesize=68049408
FrameDuration= 32.0000
Framespersecond= 31.2500
Duration=00:47:15.392
Channels mode=2/0: L+R
LFE=LFE: Not present
[Target info]
StartFrame=0
EndFrame=88605
NotFixedDelay= 8.0000
Duration=00:47:15.392
====== PROCESSING LOG ======================
Number of written frames = 88606
Number of Errors= 0

[manono]

8ms isn't typical. No one can hear any synch problems if the 8ms hasn't been taken into account. Since it's said that most people can't tell the difference up to about 100ms, even if your ears are especially sensitive it's not all that important that you adjust for 8ms or 16ms or other super low numbers. I was testing with one I had handy with a delay of -137ms and the before and after sizes were several KB different. Also, I believe you're correct that it may not adjust if the delay is less than 16ms because an AC3 audio frame is 32ms long. Your log file says that your 8ms delay wasn't fixed. WAV audio will always be adjusted because the frame lengths are much smaller. But I'm far from an audio expert and someone that knows more and knows better may want to chime in.

[spiritgumm]

thanks for checking this out, manono. Your explanation is... sound. I thought the unit size might be too small to act upon, but since the duration shows milliseconds, wasn't sure. And I agree, it won't be noticeable.
I wonder if this applies to Muxman as well?
I usually use Muxman, but was running out of time and PC space, so I thought I'd mux and author simultaneously in TDA (1.6). TDA doesn't account for delays, hence my need for Delaycut.