Audio file length in DVDMaestro

[crac]

I have been doing some work on Audio only titles on DVD-V. I have noticed something odd with DVDMaestro and wondered if anyone else has noticed it or has an explanation.

For the purposes of clarity I'll refer to durations of audio files in hours, minutes, seconds and frames (assuming NSTC video frame rate, 29.97 fps).

I have a wav file 01:37:53:04 in duration - PCM audio, 48 kHz, 24 bit. (That's how long my DAW says the file is, and I have confirmed this by taking the wav file headers apart and calculating the length of the actual number of bytes in the data chunk of the file.) When I import this as an asset into DVDMaestro, the asset bin reports it as having a duration of 01:37:47:08 - just under six seconds shorter.

I have converted this file into a DTS compressed file using SurCode DTS software. The SurCode application confirms the file length as 01:37:53:04. When the compressed DTS file is imported into DVDMaestro it also comes up short - 01:37:47:08 again.

When I place these streams in the audio tracks, they are still short. In order to have the chapter points occur in the right places within these files in the finished disc I have to adjust them by taking the real chapter timings I worked out in my DAW and multiplying them by 0.999 - the ratio between the 'real' file length and the DVDMaestro file length.

I have tried playing the finished DVD side by side with the original files on the DAW and, while the DVD might be slightly ahead by the end of the program (only using crude synchronisation in the first place, so it's a bit difficult to be sure), it is certainly not six seconds ahead. I can't hear any pitch difference, but I'm not sure I'd be able to identify 0.1% difference anyway.

I don't know what is going on, and I wondered if anyone could help. I did wonder whether there was any significance in the ratio between the two file lengths - 0.999 - being the same as that between 30 (non-drop-frame) and 29.97 (drop-frame), but can't see how this would be relevant.

Any thoughts?

Cheers,


Crac

[oddyseus]

This is exactly the case. All authoring tools r assuming u have the drop frame version inserted.

[crac]

> This is exactly the case. All authoring tools r
> assuming u have the drop frame version inserted.


Oddyseus,

Thanks for your response. The drop frame version of what exactly? Am I missing something?

Cheers,

Crac

[oddyseus]

Before u start to understand drop/non drop frame issues, u must study the 3:2 pulldown (telecine procedure) that is used in NTSC films.

U can find an excellent tutorial in this guide (http://www.doom9.org/ivtc-tut.htm) and tons of info in the rest of the web.

I have read an article at www.adobe.com about drop frame and what it stands for and I recommend to find and study it as well. I am very sorry I can't provide any usefull links on the subject. I leave to the other tv system of the world and thus my knowledge on the subject r purely theoritical and never practiced.

I can tell u that all assets that r to be used for dvd creation must be drop frame, but that is all.

[crac]

> Before u start to understand drop/non drop frame issues,
> u must study the 3:2 pulldown (telecine procedure) that
> is used in NTSC films.

> U can find an excellent tutorial in this guide and tons
> of info in the rest of the web.

> I have read an article at www.adobe.com about drop frame
> and what it stands for and I recommend to find and study
> it as well. I am very sorry I can't provide any usefull
> links on the subject. I leave to the other tv system of
> the world and thus my knowledge on the subject r purely
> theoritical and never practiced.

> I can tell u that all assets that r to be used for dvd
> creation must be drop frame, but that is all.

Oddyseus,

While I can't say I know all about drop frame and 3:2 pulldown telecine techniques, I know enough to know what it means and what is going on with it.

The reason I'm not sure if it is relevant is that timecode issues like these (I would have thought) would only apply to video material, which obviously has a frame rate, and audio material that has been compressed with an embedded timecode stamp - I think this is an encoding option with AC-3, and probably with DTS as well.

WAV files contain PCM audio with a brief header - there is no embedded timecode information. The only indication about how fast the audio should run is the actual sample frequency - 48 kHz means 48,000 samples a second per channel, and therefore defines the speed of playback. For example, if a 48 kHz WAV file has 96,000 samples in it, it will last 2 seconds, no matter what the timecode of any video it may be played with might be.

I don't see how drop frame issues / 3:2 pulldown issues can make an audio WAV file appear to be shorter than it actually is. Am I missing something?

Cheers,

Crac

[SomeJoe]

Maestro defaults to reporting timecodes in non-drop-frame format. Your WAV file is actually 1:37:54.1 in duration (HH:MM:SS.S). The SMPTE non-drop-frame timecode that corresponds to this duration is 1:37:47:08. That is NOT HH:MM:SS:FF -- it is a timecode value that doesn't actually correspond to real time.

For audio files that have an embedded time code like AC3 or DTS, the embedded timecode format is used. For WAV, or any format where there is no embedded timecode, the timecode of the video track M2V is used. Since you have no video track (you're making an audio-only DVD), you're getting the default non-drop-frame timecode.

To put chapter points into your timeline in Maestro, you'll need to either:

- Convert the real-time (drop-frame) timecodes to non-drop-frame. Or ...
- Use a .chp file where the real-time chapter points are marked with a drop-frame timecode (HH:MM:SS;FF) <<--- The semicolon before the frames number notes a drop-frame timecode. Maestro may complain when trying to import the chapter list that the timecode format doesn't match the assets on the timeline, but that's OK. The timecodes are still in the right spot.

For a proper explanation of drop-frame and non-drop-frame timecodes, see http://www.adobe.com/support/techguides/digitalvideo/timecode/timecode.pdf.

[crac]

Thanks both to Oddyseus and SomeJoe.

I guess the conclusion that I draw from all this is that this is expected bizarre behaviour rather than unexpected bizarre behaviour and that I should just apply my fudge factor to get the track points in the right place and not worry about it.

Cheers,

Crac

[TRILIGHT]

Just an idea for you crac, as most of the pertinent information has already been covered here. What sort of video clip do you have on the timeline? Perhaps if you were to put a different clip on there (that was opposite the DROP or NONDROP you have now), it might change the time display to something you feel is more appropriate to work with. Anyway, just an idea you might try.

[crac]

Trilight,

There is no video clip at all - the audio is part of a slideshow. I guess that DVDMaestro renders the slides I place on the video track to pseudo video files, but I don't get the option of picking a frame rate (other than the basic PAL / NSTC decision).

There is still something I don't get about it though - surely a second is a second no matter how many frames it is divided into. If the difference between drop and non-drop frame is the reason for the anomaly, surely that implies that a drop frame and a non-drop frame actually last the same amount of time - which they don't - I thought that was the whole point of NTSC drop frame, to change the picture frequency so that it didn't interfere with the (60Hz) mains frequency.

Anyway, I have a practical fix for the issue, so I am happy. If anyone has a real answer I would still be interested ...

Cheers,

Crac

[SomeJoe]

Originally posted by crac
surely that implies that a drop frame and a non-drop frame actually last the same amount of time - which they don't

Actually, they do. The timecode is just a label of a frame. You can think of the timecode as a "frame number". A drop frame timecode also happens to correspond to real wall-clock time. A non-drop frame timecode does not.

Your wav file is both 01:37:53:04 in drop frame, and 01:37:47:08 in non-drop frame. Both of those representations describe a file that is exactly 1:37:53.1 in duration.

Originally posted by crac
I thought that was the whole point of NTSC drop frame, to change the picture frequency so that it didn't interfere with the (60Hz) mains frequency.

No. The point of drop frame timecodes is to provide a timecode for the video that corresponds to real time. NTSC video always runs at 29.97 fps. There is no such thing as true 30.00 fps NTSC video (at least not since the 1950s - original true black and white NTSC video was 30.00 fps).

If you take NTSC video and count a timecode sequentially with the frame number going 0-29, seconds 0-59, and minutes 0-59, when you get to 1:00:00:00, you have counted 108,000 frames. However, that is NOT 1 hour of video - since NTSC runs at 29.97 fps, not 30.00, that is actually 1 hour and 3.6 seconds of video.

The drop frame numbering system takes into account the 29.97 fps rate. There are certain timecode numbers that are "dropped" from the counting sequence so that when you reach the timecode number 1:00:00:00, exactly 1 hour has passed.

Take a look at that link I posted to see the calculations and examples in detail.

[crac]

SomeJoe,

Thanks for the very helpful response. That is much clearer now - I didn't remember or understand anything like as much as I thought I had about drop-frame timecode!

Cheers,

Crac

[Ak47]

Think you'll find that the 29.97 devolves from the fact that pre-TV all framerates were film based.. 24fps or 30fps... then along came TV and TV development guys derived their frame rate as 30 fps.. just the same... electronics can do this by using a function of the AC voltage supplying the set... very easy solution for them.. as it was a pre-defined supply standard

The FREQUENCY of the AC voltage cycle is the basis for the TV framerate... 60hz in the US.. and 50Hz in the UK. However Color TV presents problems.. as there are actually 3 pictures to display.. Red, Blue and Green content... as opposed to just white.... all greys and blacks on a TV screen are only ever as black as the TV screen when it's switched off... Black = no electrons hitting the phosphor coating on the inside of the tube.

Color TV is compoled in scanlines, NTSC uses 525 lines at 60hz. odd numbered lines are drawn first, to make 1 field, then all the even numbered to make the other.. at 60Hz a frequency of TWICE the 30fps frame rate.. This method of screendraw deliberately introduces a very slight delay.. using a componet called of all things a "delay line". In NTSC terms it modifies the frame rate 29.97 as opposed to original Monochrome 30 FPS

An organization known as the Society of Motion Picture and TV Engineers then had to harmonize frame-rates/methods to allow existing and future 30fps film equipment/content capable of 29.97 Telecine to make content compatible with NTSC TV.

The answer was obvious.. existing film equipment could easily and cheaply be made to run a little slower.. with no ill effects... film and shutter movement were mechanically coupled....by just dropping a single frame every so often 30 fps could be made to run close enough to 29.97.. which is where the "drop-frame" moniker comes from...

Pulldown is another story / fix but for 24 fps based material...

Those lazy TV development guys started all the probs......

[SomeJoe]

Originally posted by Ak47
This method of screendraw deliberately introduces a very slight delay.. using a componet called of all things a "delay line". In NTSC terms it modifies the frame rate 29.97 as opposed to original Monochrome 30 FPS

film and shutter movement were mechanically coupled....by just dropping a single frame every so often 30 fps could be made to run close enough to 29.97.. which is where the "drop-frame" moniker comes from...


Neither of those statements are correct.

There is no inherent delay in the method of electron beam drawing on the screen. All delays in the process are accounted for because the signal timing is for 525 lines, but only 486 are drawn on the picture tube. The remaining 39 "lines" are actually time delays used for retrace, sync, and line 21 data transfer. There is no "delay line" or "delay circuit" designed to slow the frame rate down. Precise frame rate is maintained with a phased-locked-loop circuit synchronized to the incoming signal sync pulses. The power line frequency is not used for synchronization (and never was, it is too inaccurate).

When color TV was introduced in the 1950s, the frame rate was changed to 29.97 vice 30.00 specifically to place the energy bands of the 3.579545 MHz color subcarrier in between the energy bands of the luminance signal. This minimizes the interference and cross-talk of the luminance and chrominance signals. Further, 29.97 fps was within the tolerances of black and white TVs designed for 30.00 fps, and their PLL circuit could continue to maintain synchronization and display a black and white picture from a color signal.

To further reduce the aforementioned interference, "comb filters" were later developed which remove the color subcarrier energy from in between the energy bands of the luminance signal. Since the two energy patterns are interleaved up the entire spectrum of the signal, the name "comb filter" was used because the process can be visualized the same way as the teeth of a comb running through someone's hair.

When film is transferred to video, there are no frames dropped. Nor are there frames dropped when using a drop-frame timecode. The "drop-frame" name does not come from throwing away any video information -- it comes from skipping frame numbers. Further, the drop-frame timecode system does not have anything to do with film rates or the telecine/3:2 pulldown process. 24 fps film is transferred to video by slowing the film down to 23.976 fps, and them applying 3:2 pulldown to achieve 29.97 fps.


Before you post in a technical discussion you need to research and be sure of your facts.

[Ak47]

Originally posted by SomeJoe
Neither of those statements are correct.......

Before you post in a technical discussion you need to research and be sure of your facts.

Somejoe...

I dislike the argumentative tone of your post but.... in relation to the comments you make...

You assume in your response that my post refers to the technical aspects of NTSC timecode... it does not except as a general description of the process...

if you read the title of the thread it relates to audio file length and audio sync. My comments go to the historical facts regarding establishment of the "drop-frame" standard.... like it or not the current standards are based on the capabilities of the old technology... but perhaps you'll accept the word of an Emmy award winner in the film audio field instead.

I refer you to the link below....

http://www.uemedia.com/CPC/printer_11330.shtml

Oh and btw.... what was that you were saying about research ???

[SomeJoe]

Originally posted by Ak47
I dislike the argumentative tone of your post but.... in relation to the comments you make...

You assume in your response that my post refers to the technical aspects of NTSC timecode... it does not except as a general description of the process...

if you read the title of the thread it relates to audio file length and audio sync. My comments go to the historical facts regarding establishment of the "drop-frame" standard.... like it or not the current standards are based on the capabilities of the old technology... but perhaps you'll accept the word of an Emmy award winner in the film audio field instead.

I refer you to the link below....

http://www.uemedia.com/CPC/printer_11330.shtml


My post is not argumentative. Unfortunately, a threaded discussion forum cannot convey nuances of speech such as tone. My "tone" in that post was matter-of-fact and educational.

In reference to your link, the author of that link is correct in virtually everything he says, and it's clear that he understands it well. There are a few places in his write-up where the explanation is a bit awkward, but the reader can infer what he means.

The issue I have with your post were two statements you made that are not accurate (and not in agreement with the author from your link, either). Understanding of NTSC timecode idiosyncracies is a recurring theme on this forum, and one that gives people no end of headaches when trying to manupulate NTSC video. It would be a disservice to the forum to not present factual information, or to not clear up misinformation when presented.

I disagree with you that your post refers to a "general description of the process". You specifically discussed power line frequency, screendraw and vertical retrace delay, and the telecine process. I submit that you indeed did refer to technical aspects of the NTSC timecode.

Indeed, the historical facts and history of development of the NTSC drop-frame timecode have their roots with the SMPTE, but this is not what your previous post was referring to, nor is that what I referred to in my rebuttal.

The objective of the forum as a whole is to discuss and disseminate accurate information for everyone who reads here. By working together, we will accompish such. Do not view this post or previous ones of mine as argumentative or personal. We all live and learn.

[Ak47]

I disagree with you that your post refers to a "general description of the process". You specifically discussed power line frequency, screendraw and vertical retrace delay, and the telecine process. I submit that you indeed did refer to technical aspects of the NTSC timecode.

I agree I have referred to certain technical aspects of the NTSC TV standard.. but only in the most general terms... power line frequency must be included in a discussion of 29.97fps df standards, as it's the entire basis for the original 30fps ndf. Likewise with the other aspects mentioned... Color NTSC requires 29.97df to overcome certain problems inherent with screen display.. as has been discussed and as you detailed, in technical fashion, in your "rebuttal".

The audio and film industry use 29.97df only to be compatible with NTSC TV display. Prior to NTSC color TV 30fps was defined as the industry standard and remains so.. The Telecine process resolving the differences in the frame-rates... The vast majority of DVD content is actually filmed at framerates beyond 30 fps.. which is then resolved to 30 fps for editing. TV filming/recording/broadcast is an entirely different animal.

All of the timecode standards are designed around making audio synch backwards compatible.. avoid throwing away existing equipment. Color NTSC TV has introduced a lot of problems in relation to audio synch.. a major shortcoming that was not forseen by the original Monochrome NTSC 30fps ndf standard.

It is apparent that you have some kind of NTSC Technical background.. my own background is in the Audio recording industry... we deal with timecodes a lot.. and the evolution of timecode has it's roots in our industry.

To suggest that my initial post was not concerned with the historical development/evolution of the 29.97 drop-frame standard, as opposed to the technical specification of the NTSC standard, is to have mis-read it entirely.