edited DVD using DVD Shrink / Muxman / PGC Demux - differences in total

[efc1978]

Hi,

This might have a simple explanation, I don't edit DVD's very much so don't have much knowledge in this area, however everything seems to be working OK except I've seen some contradicting total run time lengths for my DVD and I'm not sure why?, and if it's a problem?

I had a 2 hour music DVD I changed the song order by putting the songs in the order they were actually played at the live show (on the DVD they were not in the order they were actually played at the live show).

So I split up the sections of the DVD I wanted to cut using DVD Shrink, I then split the video and audio of each section into m2v's and Wav audio using PGC Demux.
As cutting with DVD Shrink messes with the delay I wasn't sure how to sync 5 blocks back together so I figured I needed to find the exact length each m2v will hold of audio, so I muxed each m2v with an audio file longer than the m2v and then split out the audio file from the m2v using PGC demux, so for example a 160371 frame 29.97fps m2v gave a 1h29min11sec.045 audio file, and a 6940 frame m2v gave me a 3min.51sec.56333 audio file, so I figured everything should stay in sync if I made each individual audio file the same length as it took the 'fill' the m2v's, I found the delay for each, and cut that much off the start of each audio to fix the delay, and added some silence to the end of each track to fill to the end of each m2v, I then merged all the audio into 1 big audio file, and muxed it with the 5 m2v files so I now have a DVD (which I also tracked using celltimes text). *I'm not sure if the process I just described will make sense to others but I'm pretty sure it works to get everything back into sync!
Everything looks in sync and plays fine, but I'm not sure why I'm seeing some contradicting time lengths for the DVD, opening in TMPGEnc it says the DVD is 213001 frames and the audio is 1h58min.27secs.13 which makes sence, however opening in DVD Shrink it says the tile is 1h58min.20 secs, my Blu ray player also says 1h58min.20secs and PGC demux says 1h58min20secs, but I know the DVD should really be 1h58min27secs.13 as TMPGEnc says because the files on my hard drive I worked with are 1 audio file 1h58min27secs.13 and the m2v's are 160371 frames + 6940 frames + 5545 frames + 15287 frames and 24858 frames.
Why are some showing 1 hour:58mins20secs and others showing 1hour58mins27secs?, I'm certain it's really 1h58min.27 secs, but not sure why some programmes are saying it's 7 seconds less?
Thanks

[manono]

Probably drop frame .vs non-drop frame timing. 29.97fps .vs 30fps. I wouldn't worry about it, if I were you.

[efc1978]

Thanks, yeah it all seems to play fine and definitely looks in sync,
it just seems 7 seconds is a big amount of time to disappear!, but I kind of understand what you mean...
Thanks

[efc1978]

I don't know much about video and am kind of doing some 'experimenting' here.
Is the amount of audio length that fits/fills the length of an m2v going to be mathematically precise?, or will there be difference?
I've worked out that 1 frame at NTSC 29.97fps would be I think 0.0333667000333666 seconds long if I'm correct.
So for example I have an m2v which is 6940 frames, so you would expect it takes 3min51.5648982315600 of audio to 'fill' the length of the m2v.
But if I use Muxman and mux the m2v with audio that is much longer than the m2v and then use PGC Demux to split out the audio I presume that is the total capacity of audio it takes to 'fill' the length of the m2v?, in this case the audio was 3min51secs.56333, not what I had mathematically calculated (the time I wrote a few lines above).
Another example is mathematically a 15287 frame m2v should take 8min30secs.0767434100660 of audio to fill the length of the m2v, but using the process I described above to 'fill' the m2v length when I used PGC Demux to split out the audio after I ' filled' the m2v length the audio was 8min30secs.075.
Does that mean extracting the audio with PGC Demux loses some audio?, or more likely the length of audio it takes to fill the length of the m2v is not absolutely what the maths would tell you?
It's very small differences but seeing as I'm syncing video/audio was trying to make it very precise.
Looks to have worked nicely but was just wondering if maybe you can't really be 100% accurate in calculating how much audio will fill the length of the m2v...

[manono]

If you ask me, I think you're just wasting your time.

[efc1978]

It may be considered wasting time if I haven't got 10 minutes of my precious life to spare, but that wasn't the question I asked...
The answer is pretty simple to answer myself anyway, as a 15287 frame m2v should mathmatically take 8min30secs.0767434100660 of audio to fill to the length of the m2v, and I mux the m2v with an audio file that is much longer and get a slightly shorter audio file when I demux which is 8min30secs.075, to see if PGC Demux is ever so slightly cutting the audio file short all I have to do is mux the audio file again with the m2v, and demux again, hell I could even repeat the mux and demux process a few times, and each time I still get an audio file of 8min30secs.075, which would answer my question = PGC Demux doesn't slightly shorter the audio file when demuxing, and it seems that if you mux an audio file longer in length than the m2v with the m2v the audio file you demux doesn't mathmatically precisely match the length a calculation would tell you that you would get if you multiply the frames in the m2v by the length of each frame 29.97fps = 1 frame 0.0333667000333666 seconds long, it's going to be a bit different.
There you go, I answered myself, took a whole of 5 minutes to do the expirement!

[hello_hello]

Technically, 29.970 is a "rounded" frame rate. 30000/1001 is not. That makes the frame duration 33.3666666666666666667ms
http://avisynth.nl/index.php/FPS

I'm not sure how much that changes things, but what sort of audio are you working with? Lossy audio is stored in frames so it generally can't be cut precisely. Lossless audio.... I've no idea really but as a quick test I muxed a wave file into and MKV (as MKVToolNix writes tags that make MediaInfo more informative) and had a look.

Sampling rate : 44.1 kHz
Frame rate : 5.001 FPS (8818 spf)

I'm not sure how stuff is normally stored in wave files, and that's almost 200ms frame sizes for MKV, which seems fairly large, but it's how it seems to store wave files. Here's what the timecodes looked like around the 60 second point.

58399.993338
58599.993338
58799.993338
58999.993338
59200.00008
59400.00008
59600.00008
59800.00008
60000.006822
60200.006822
60400.006822
60600.006822
60799.99089
60999.99089

When I asked MKVToolnix to split the output every 60 seconds it did just that. I tried again splitting at 59 seconds and got 59s 200ms.
44100 x 59200 / 1000 = 2610720 samples and that's what came out according to foobar2000.

Mind you math still doesn't quite work out as 2610720 isn't as evenly divisible by 8818 as I thought it should be. Maybe the answer lies in what appears to be jitter in the MKV timecodes.... but anyway.... just some thoughts. I know nothing about m2v but maybe it's a frame size thing?

Out of interest, I also put the same wave file in an MKV (on it's own) with GDSMux and ffmpeg. It appears GDSMux uses slightly larger frame sizes which work out to about 250ms, while ffmpeg keeps them nice and small and just over 23ms. I guess it's not set in stone, at least for wave files.

[efc1978]

Not sure about this stuff. All I've really looked at is the stuff I described in my post using .wav audio and .m2v video.
My project has turned out satisfactory, even the drum sticks hitting the snare drum look in sync at the end of my video, so all has worked OK.