Audio Desync on Videos with VFR FrameRateMode if the "Original" and actual framerate differ about staxrip HOT 17 CLOSED

Audio is Copy/Mux'd btw

from staxrip.

If there a delay needed for the audio it's handled by Mediainfo, if Mediainfo doesn't state there a delay StaxRip doesn't create delay for the audio.

Mediainfo 18.08 should not be used due to the bugs.

from staxrip.

I dont see any information about Delays either with 18.0.0 or the MediaInfo directly in StaxRip 1.9.0.0

from staxrip.

Also its not typically a "delay" its more like it linearly grows in delay. as in at very start delay of 0, and by the end there would be maybe half a second delay.
sometimes its weirder and would be half a second delay up to the middle of the video, then starts slowly going back to no delay at the end of the video.
Both of these sources are loaded with FFVideoSource (automatic used) and are "MPEG1/2" but I believe they are MPEG2 as they are sourced from old DVD's

from staxrip.

What I have noticed as mentioned in the reddit post is the difference in Framerate to original framerate, if I were to encode inside of Handbrake it would work fine. Odd enough, handbrake's source actually says its 23.98 (24000/1001*10 rounded up) so its probably working off "Original Frame Rate" rather than "Frame Rate", perhaps there's a way to properly do this with StaxRip? I know of the filters but which one is the better of them, there's many variants.

from staxrip.

I added another example of when it DIDNT de-sync: https://www.reddit.com/r/staxrip/comments/9tzo32/1900_audio_desync_on_videos_with_vfr/
So this kinda confirms it should be encoding by "Original frame rate" over "Frame rate" if it exists.

from staxrip.

If there no data about the delays then StaxRip has no way of knowing about it. HandBrake uses FFMPEG probe for there system to detect delays.

Without having a sample I can't really do much without having the source material.

You also need to be careful on the filters you use if they affect the audio/FR or not. I know one effects the audio and it doesn't correct the audio in the process and ms delay has to be recalculated.

I think there something else going on, Since I have zero reports of audio desync.

I would avoid VFR, it's 100% useless and dumb to use in the first place. I have no idea why Handbrake added that in the first place. It does nothing but create problems. If anything it makes the video look worse then better.

Video rate could drop all the way down to 15fps if you use VFR.

Might want to post here to see if anyone else has experienced the same kind of issue: https://forum.doom9.org/showthread.php?t=175845

from staxrip.

Again as I mentioned, you basically just need to read fps on "Original frame rate" Tag instead of "Frame rate" tag if the source is VFR and if that tag exists. Also ive done all these tests with no filters only "Source".
Also again im not trying to encode to VFR, just sources that are already VFR are what cause this, if I could avoid I would but I cant.

from staxrip.

It's a problem with MediaInfo some one else if having issues with VFR and reporting incorrect data: MediaArea/MediaInfo#293

Once that gets corrected you shouldn't have any issues. In the mean time download and use an older version (Pre 18.08 builds).

You can also add AssumeFPS(24000, 1001)

If your using Vapoursynth you can unspec everything & Re-Spec it to proper video data.

Example:

clip = core.resize.Point(clip, matrix_in_s="unspec",range_s="limited")
clip = core.std.AssumeFPS(clip, fpsnum = int(%media_info_video:FrameRate% * 1001), fpsden = 1001)
clip = core.std.SetFrameProp(clip=clip, prop="_ColorRange", intval=1)

fpsden can be 1001 or 1000.

FYI, I'm pretty sure num value of 23976 is improper value, I've never come cross such a value. It's always 240000/1001. There so many different values for framerate it could be one of those rare cases.

It took Mediainfo close to a year to get HDR color corrected in the tool, Which I first reported to them in November 2017. It was only fixed a months or to ago. Who knows when this bug along with all the other bugs I've found in Mediainfo to be addressed.

I've reported all them, atlease they are aware of them.

from staxrip.

Also handbrake didnt do shit, I said I used handbrake to convert the VFR source to CFR as it uses "Original frame rate". So just use Original frame rate on StaxRip and your good.

from staxrip.

Do you mean install an older copy of it or put an older copy of it in StaxRip Directory? I really dont think its to do with MakeMKV, also when I did AssumeFPS it did in fact work better but since it wasnt the EXACT "Original frame rate" to the closest value possible, it was still off, but not near as much.

from staxrip.

Also I would give you a sample file but its not exactly legal.

from staxrip.

Do you mean install an older copy of it or put an older copy of it in StaxRip Directory? I really dont think its to do with MakeMKV, also when I did AssumeFPS it did in fact work better but since it wasnt the EXACT "Original frame rate" to the closest value possible, it was still off, but not near as much.

In the Directory, Head over to 1.9 Link it has older MediaInfo that works or you can upgrade to 2.0 Beta.

MediaInfo has broken file extensions, subtitles and a few other things from there latest release.

from staxrip.

I really dont think you understand the actual issue here.
MediaInfo, Handbrake, FFMPEG, e.t.c have nothing to do with this.
If I were to AssumeFPS to the exact number of "Original frame rate" this issue does not occur, but it has to literally be bang on to the closest decimals.
If I dont, it will use "Frame rate" (Not "Original frame rate") resulting in it using lets say 24 fps instead of 24001/1001 (23.976) resulting in the issue.

from staxrip.

For files that are variable frame rate but reporting constant you need to change the time codes for the orginal files video track before running staxrip.

fix audio sync when video track is variable frames

working fix
get the time codes the for the video and audio tracks where tc0 is TRACK1 and tc1 is TRACK2
"D:\staxrip\Apps\MKVToolNix\mkvextract.exe" timecodes_v2 "D:\badsyncefilename.mkv" 0:"D:\batch\filename_tc0.txt" 1:"D:\batch\filename_tc1.txt"

write a new file with frame rate

"D:\staxrip\Apps\MKVToolNix\mkvmerge.exe" --timecodes 0:"D:\batch\filename_tc0.txt" -o "D:\output_fixed_sync_filename.mkv" "D:\badsyncefilename.mkv" --ui-language en

when merging --timecodes 0:"TIMECODE_0.txt" must be at the begining or it will not take effect.

verify by checking the media info and the videos frame rate should change to variable from constant.

Now run staxrip on the new file you created and it should work.

from staxrip.

I really dont think you understand the actual issue here.
MediaInfo, Handbrake, FFMPEG, e.t.c have nothing to do with this.
If I were to AssumeFPS to the exact number of "Original frame rate" this issue does not occur, but it has to literally be bang on to the closest decimals.
If I dont, it will use "Frame rate" (Not "Original frame rate") resulting in it using lets say 24 fps instead of 24001/1001 (23.976) resulting in the issue.

This isn't a StaxRip issue by any means.

from staxrip.

Jesus fucking christ, as I said, just take "Original frame rate" when it exists, solved. You clearly dont understand wtf I mean even though I explain it 5 fucking times

from staxrip.