The demuxed AAC from a MP4 file is wrong

[poisondeathray]

I think this version is just default. You can find all versions here

https://www.videohelp.com/software/eac3to/old-versions

[elektro]

I think this version is just default. You can find all versions here

https://www.videohelp.com/software/eac3to/old-versions

Strangely enough, this older version 3.27 fixed the audio... I need one more thing: how to save the result to wav instead of aac? I still get errors with either Nero AAC Decoder and Libav.

LE: I found this thread from a decade ago where someone had to deal with the same kind of issues and you replied too: https://forum.videohelp.com/threads/370901-25fps-AAC-to-23-976fps-AAC-%28slowdown%29

What a bad idea to make a whole program rely on some stuff by other companies installed instead of including all necessary dependencies.

[poisondeathray]

Strangely enough, this older version 3.27 fixed the audio... I need one more thing: how to save the result to wav instead of aac? I still get errors with either Nero AAC Decoder and Libav.

It's probably just a different setting like 2pass was default before

use output.wav instead of output.aac

What are the errors exactly ? Post the log

[poisondeathray]

LE: I found this thread from a decade ago where someone had to deal with the same kind of issues and you replied too: https://forum.videohelp.com/threads/370901-25fps-AAC-to-23-976fps-AAC-%28slowdown%29

What a bad idea to make a whole program rely on some stuff by other companies installed instead of including all necessary dependencies.

I think at the time, open source AAC encoders were terrible (they have improved significantly now, but are still not as good) , and even decoding had differences

Today, for AAC encoding, the best is probably QAAC . There are plenty of comparisons now, there is a lot of evidence . Some people pipe eac3to to QAAC , or you can output wav and use QAAC directly . There might be a way to use it directly in eac3to - I'm not up to date on the audio stuff

[elektro]

Strangely enough, this older version 3.27 fixed the audio... I need one more thing: how to save the result to wav instead of aac? I still get errors with either Nero AAC Decoder and Libav.

It's probably just a different setting like 2pass was default before

use output.wav instead of output.aac

What are the errors exactly ? Post the log

This is the log:

eac3to file.mkv result.wav
MKV, 1 video track, 1 audio track, 0:06:13, 60i /1.001
1: MPEG2, 1080i60 /1.001 (16:9)
2: AAC, 2.0 channels, 48kHz, -100ms
Track 2 is used for destination file "result.wav".
a02 Extracting audio track number 2...
a02 Decoding with DirectShow (Nero Audio Decoder 2)...
a02 Getting "Nero Audio Decoder 2" instance failed.
Aborted at file position 786432.

There is something wrong with Nero Audio Decoder 2. I even installed Nero 6 & 7, same result.

[poisondeathray]

I get the same error for output.wav - because Nero Audio Decoder 2 not installed for me either on this computer. I probably had it installed on some older computers, probably XP era when Nero was popular

aac is ok, because it's just looping and shifting samples for the "Realizing AAC gaps..." . This is not decoding and re-encoding

[elektro]

I get the same error for output.wav - because Nero Audio Decoder 2 not installed for me either on this computer. I probably had it installed on some older computers, probably XP era when Nero was popular

aac is ok, because it's just looping and shifting samples for the "Realizing AAC gaps..." . This is not decoding and re-encoding

So, the gaps are filled in a lossless way by eac3to? In that case, I'll just use the aac output.

Thanks for help.

[poisondeathray]

I get the same error for output.wav - because Nero Audio Decoder 2 not installed for me either on this computer. I probably had it installed on some older computers, probably XP era when Nero was popular

aac is ok, because it's just looping and shifting samples for the "Realizing AAC gaps..." . This is not decoding and re-encoding

So, the gaps are filled in a lossless way by eac3to? In that case, I'll just use the aac output.

Lossless in the sense that the original samples are preserved, just "moved"

But if you apply other stuff like filter, normalize - that's no longer "lossless" . But I would expect it to complain if you tried since Nero Decoder isn't installed

[elektro]

I get the same error for output.wav - because Nero Audio Decoder 2 not installed for me either on this computer. I probably had it installed on some older computers, probably XP era when Nero was popular

aac is ok, because it's just looping and shifting samples for the "Realizing AAC gaps..." . This is not decoding and re-encoding

So, the gaps are filled in a lossless way by eac3to? In that case, I'll just use the aac output.

Lossless in the sense that the original samples are preserved, just "moved"

But if you apply other stuff like filter, normalize - that's no longer "lossless" . But I would expect it to complain if you tried since Nero Decoder isn't installed

I thought the app decodes the original AAC to WAV, fill in the gaps then re-encodes it back to AAC. If it works directly on the original AAC and doesn't mess with the rest of the audio, then it's ok. I can edit the result in a different app.

[Alwyn]

I compared the TFM/TDec version with the VRD-processed version and they are within one frame of each other the whole way though. 6m8s10f long. I spotted one dupe, right after a scene change. Interesting that 2 different processes come up with the same result. I still think it's the video that's wrong, not the audio.

[poisondeathray]

I compared the TFM/TDec version with the VRD-processed version and they are within one frame of each other the whole way though. 6m8s10f long.

Interesting that 2 different processes come up with the same result.

You would expect an inverse telecined version to match the telecined version in terms of timing, even if it's a botched version from VRD processing

I spotted one dupe, right after a scene change.

When VRD remove the wrong frames, then IVTC is applied - cadence breaks and wrong matches lead to more duplicates being placed, with additional drops

I still think it's the video that's wrong, not the audio.

They are both "correct" , but there is a A/V length discrepancy.

Definitely VRD is creating mistakes and making the video "more wrong" , because incorrect frame drops are easy to see - you can see the jumps in "Bring Me the Horizon feat. VRD QSF Recode.mp4" in post #7 even before TFM/TDecimate . Those frames are present in the original, and in a correctly IVTCed version

Here are a few clear drops in that video (pre IVTC frame numbers, there are more)
4018-4019
6553-6554
7596-7597
8771-8772
9449-9450

The dropped frames breaks the 3:2 cadence in sections, creating more incorrect matches leading to duplicates and more incorrect frame drops after IVTC. So after IVTC, it's similar problems as listed in post 24 , the numbers and framecount are slightly different than the OP's version not sure why, maybe you guys are using different VRD versions

There are additional errors with "VRD QSF Recode", such as chroma ghosting in the fields . Almost as if an incorrect progressive chroma resampling was applied- perhaps an RGB conversion - while still in interleaved fields . OP's version processed with VRD did not have those errors. You can use AssumeTFF().SeparateFields() and take a look - many of the fields are botched - especially in the 2nd half where there is more motion


[Attachment 88379 - Click to enlarge]

[Alwyn]

@PDR, thanks for that. I understand your points re VRD.

To be clear, my comparison was between the VRD version and the TFMed original file. I did not TFM the VRD version.

I've lost track of what you would suggest re the video; are you TFMing it and if so, what code are you using?

[poisondeathray]

Yes, standard IVTC e.g. TFM().TDecimate() on the original video . You can adjust the TFM parameters, for example he was using QTGMC for clip2 - and there are a few combed sections so it's actually being used

ie. Don't use videoredo quickstream fix. It's a great program usually, but messes this stream up for the video stream

The video should be 6:12.246 after IVTC. If you 're getting something different, check your source filter, or that repeat field flags are being honored

6:09 @ 23.976 CFR means you're dropping frames. You're missing ~3 seconds of data compared to a proper IVTCed version with unique frames - so you'd expect about 70-80 good frames dropped , not counting the duplicates .

[Alwyn]

I tried Libav, ffms2, ffvideosource, LSmash. 2 failed with errors, the other two gave me a 6min 9sec file using basic TFM and TDec.

What exact code are you using?

[poisondeathray]

See post #21 . FFVideoSource with rffmode=1 . Don't use pp=0 , because there are sections with combing - that was just for a preview and to check sync with the processed audio

For the versions of Lsmash I'm using,

LSmashVideoSource gives the wrong framerate 25.737, and the wrong framecount, doesn't honor flags .

LWLibavVideoSource gives the correct framerate, correct framecount and honors flags . Same result as ffms2 with rffmode=1

[Alwyn]

I'm confused. Parts of the video are progressive. Look at frame 2883 on. No combing, DR deinterlacing shows Progressive.

Other parts have significant combing.

It seems that the long-range camera on stage centre is showing combing but the side cameras aren't.

[poisondeathray]

I'm confused. Parts of the video are progressive. Look at frame 2883 on. No combing, DR deinterlacing shows Progressive.

Other parts have significant combing.

It seems that the long-range camera on stage centre is showing combing but the side cameras aren't.

Which video ? Which source filter ? 2885 has combing . 3 clean , 2 combed. ie. 3:2 telecine

Make source you honor flags

[Alwyn]

Which video

The MP4 from post #1. I'm opening it in VDub2.

2883 and on for a bit-no combing at all.

3120 and on for a bit: combing. It may be a coincidence, but when those bright flashes occur, the combing is worse.

[poisondeathray]

Which video

The MP4 from post #1. I'm opening it in VDub2.

2883 and on for a bit-no combing at all.

3120 and on for a bit: combing. It may be a coincidence, but when those bright flashes occur, the combing is worse.

vdub2 with the caching input driver is not honoring repeat field flags . That makes it difficult to IVTC properly because it's a mixed stream.

[poisondeathray]

In vdub2, if you use mpeg2-index instead of the caching input driver (in the open video file dialog box, the files of type drop down) , the flags will be honored

[Alwyn]

Arh ha. I'm now unconfused!