I see the same results on 365 (18.1.2405) when using QuickSyncon a Surface Pro 3, and I see similar results when running 18.0.2405 using nVidia HA on my desktop.

Obviously there's no AAC 5.1 there since it was only added in the latest patch, so I used DTS 5.1 on the MKV (it was grayed out for the MP4) and also TrueTheater for MP4 and MKV:



It seems like there were already timing differences between the original PD18 audio modes, and that's carried over when AAC 5.1 was added.

YouTube/optodata

DS365 | Win11 Pro | Ryzen 9 3950X | RTX 4070 Ti | 32GB RAM | 10TB SSDs | 5K+4K HDR monitors

Canon Vixia GX10 (4K 60p) | HF G30 (HD 60p) | Yi Action+ 4K | 360Fly 4K 360°

Quote It seems like there were already timing differences between the original PD18 audio modes, and that's carried over when AAC 5.1 was added.

optodata, it's been a issue for a long time and many formats, yes PD18 initial release, PD17, PD16...so on, one such post of several I showed 8+yrs ago, https://forum.cyberlink.com/forum/posts/list/20086.page#post_box_106070 on the poor timeline accuracy. I just thought perhaps since CL has been working on timeline waveforms and with the release of a few new audio formats for certain containers they would have scrubbed and provided something reasonable.

What was stated 8+ yrs ago is still the norm, "Bottom line, one can pseudo gage the appropriate position in a timeline to add events but it is nothing near accurate."

Jeff

I am glad I am not the only one who finds the waveforms unacceptable in PD. I thought I was the only one. On top of them not being very accurate, they are pixelated and not well visiable unless you zoom in very very close (like 1 second spans the whole length of your screen). They are much better in every similarly priced video editor.

I was syncing the sound on a Noir movie tonight and noticed something about the Audio Waveforms that I've never noticed before. Maybe it is part of the reason why waveform audio is not precise?

Usually when I sync sound, I shift the video track back and forth. (After unlinking the audio from the video of course.) But tonight I shifted the audio track.

As you can see in the short (admittedly fuzzy) video I made, I discovered something surprising. The audio waveforms don't update in real time. (In contrast to the thumbnails on the video timeline.)

https://streamable.com/6svj6

If PD18 is still using the same paradigm for audio waveform information that is used on PD15, then a txt file is created that holds waveform information. Apparently the data is not granular enough or is not updated/cached to repaint when moved. If this is part of the problem with waveforms, then perhaps another paradigm is needed?

pmikep, the repainting of the waveform is another longtime audio waveform issue, but I'd think different than what I trying to show.

You can often get the waveform to repaint by zooming out and then back in on the timeline, using the "View entire movie" icon, or simply move the timeline scrubber, are a few methods that usually work.

In this case I was trying to show the waveform will always be painted like shown with alignment differences, it just appears as a poor representation of real time construct so everything is off a few frames relative to another PD encoding of the same file.

Jeff