AC3 headers / determain duration

[D3s7]

Trying to extract the duration of an AC3 by looking at the AC3 header information.

I've been able to extract/process most of it but when I get to the timecod1- timecod1e exists but when I pull timecod1 I'm getting back the movie is 17hours 35min 4sec (Timecode i extract is 10001110111110)

I'm hoping I'm just misprocessing that timecode by converting it to decimal (5bit - 6bit - 3bit)

Anyone have any suggestions on how to extract duration accuratly?

I'm getting the ac3 specs from mpucoders page on it and coding in VB

Thanks

- D3s7

[KpeX]

Hi -

Don't think you'll get much help here in Audio Encoding, so I'll move this to development. Good luck.

[mpucoder]

How are you determining the length by reading a timecode? Are you looking at the last - first timecode? It doesn't necessarily start at 0:00:00

Also, make absolutely sure of your position in the BSI, there are several optional fields prior to the timecode. And, make sure BSID == 8, if it is 6 you have an A52a frame, with no timecode.

[fccHandler]

It might be easier just to guesstimate:

If the AC-3 stream is CBR:
duration = (file_size_in_bytes * 8) / ac3_bitrate.

If the AC-3 stream is VBR:
duration = (total_number_of_ac3_frames * 1536) / sampling_rate.

(...where "duration" is given in seconds.)
HTH

[D3s7]

MPUCoder : time code listed in each BSI for that specific frame correct and duration woudl be (time of last frame) - (time of first frame) ?

guestimate may work.... I just need it to be fairly close for scenarist to except it...
There an easy way to tell if it's VBR/CBR? I didn't see any info specific to that short of scanning some frames and reading the bitrate

Thanks!

[fccHandler]

To be honest, I've never seen a VBR AC-3 in my whole life (though nothing in the ATSC standard forbids it). The only way to be 100% certain is to scan every AC-3 frame and compare their bitrates. If they all have the same bitrate then the stream is CBR, otherwise it's VBR by definition.

However, I'll bet money that if the stream came from a DVD, then it's surely CBR.

[diehardii]

I have some code for an AC3 parser around here somewhere if you're interested. I've never tested this functionality (it is a MSoft sample), but it might provide some insight. PM me if you would like it.

~Steve

[DSPguru]

Originally posted by fccHandler
However, I'll bet money that if the stream came from a DVD, then it's surely CBR. hold your horses. there are movies with audiostream that starts with 448kbps ac3 for a few seconds and later changes to 384kbps :
http://forum.doom9.org/showthread.php?s=&threadid=14139

[D3s7]

diehard : yeah if you have code I wouldn't mind seeing it... I'll shoot you a PM too

DSPguru : oh great.. that's not what I wanted to hear :D

Basically I'm attempting to parse the file enough to get 1) duration, 2) bitrate, 3) channel info. All of this will be eventually dumped into Scenarist so it needs to be fairly accurate

[fccHandler]

Originally posted by DSPguru
hold your horses. there are movies with audiostream that starts with 448kbps ac3 for a few seconds and later changes to 384kbps :
http://forum.doom9.org/showthread.php?s=&threadid=14139
Woah! That sounds like it could have been a splice between the (FBI warning / THX logo / studio logo) and the actual movie. Not exactly my idea of a VBR AC-3 stream, but it's still a nasty thing to find on a DVD... :scared:

[fccHandler]

Originally posted by D3s7
Basically I'm attempting to parse the file enough to get 1) duration, 2) bitrate, 3) channel info. All of this will be eventually dumped into Scenarist so it needs to be fairly accurate
I think the "a52_syncinfo" function of liba52 (http://liba52.sourceforge.net/) (in parse.cpp) would be ideal for this purpose. For a working example you may also want to look at the source code of my AC-3 ACM decompressor (http://fcchandler.home.comcast.net/AC3ACM).

[D3s7]

Taking a look at the source right now.. THNX

although I'm not seeing duration in that (biggest part I need)

[fccHandler]

Well, the "int" returned by the function is the size of the whole frame in bytes (so it's easy to find the next frame). IIRC, each AC-3 frame contains exactly 1536 audio samples, so the duration of each frame in seconds is 1536 / sampling_rate.

[D3s7]

Well I made some progress but it appears I might have to scan every frame to find the accurate duration according to Scenarist

For example one I'm working on:
Sampling rate: 48 kHz
Nominal bit rate: 448 kbps
Framelength: 0x0700
Length: 21494frames (00:11:27,808)
There are 31.25 frames in one second.
(info taken from ac3delaycorrector and verified by ac3frame header info

Scenarist reports that as 00:11:27:03 (nondrop) or 00:11:27:23 (drop)

if I try to convert 808ms to frames it's appears to be 808/1000*31.25 = 25.25 which is close to the dropframe calc but 2.5 frames off

[fccHandler]

Originally posted by D3s7
There are 31.25 frames in one second.
This statement might be causing confusion. There are 31.25 AC-3 frames per second, but that is not the same as SMPTE time code frames. From what little I know about SMPTE, I think "nondrop" is 30 fps and "drop" is 29.97 fps, and maybe you (or Scenarist) is calculating incorrect time codes based on 31.25 fps?

[D3s7]

Could be....

the hour:min:sec match up on both.. it's just the remainder ms / frames that aren't aligned..

maybe there needs to have some math done from one rate to another to get the proper frame remainder