"Raimund" wrote
John Lundsten wrote:
> I'm getting some strange readings from these 3 files
> Nnoc T0000002.WAV
> Nnoc T0000012.WAV
> Ppip T0000021.WAV
>
> The EBU chunk viewer refuses to open the files
> EDL Convert doesn't recognise the bext chunk or the sample rate
> Widget Pro sees the sample rate as 44.1k.
> Fostex BWF Manager, Total Commander, Adobe Audition, Sony Vegas Pro &
> Sound
> devices Wave Agent see the sample rate as =3D250k
>
> Now whilst 48k is the "assumed" sample rate of a BWF other sample rates
> are
> allowed. But 250k being way higher than most apps would expect (& DAW's t=
o
> play) I can imagine they will not have programmed for this possibility.
Yep, 250 kHz is really a very uncommon sample rate for these applications
and one cannot expect that every audio software is able to intrepret it
correctly.
> Using "Nnoc T0000002.WAV"
> The timestamp is read as:--
> BwavWriter =3D 00:01:02:10.2 ( not clear to me what sub second units ar=
e
> being used here, certainly there is no FPS setting)
This would be the correct reading. According to the BWF specification
(http://www.ebu.ch/CMSimages/fr/tec_doc_t3285_tcm7-10544.pdf), the bext
chunk contains a 64 bit integer number ('TimeReference') that represents th=
e
sample count since midnight. In my RECORDER software however, this number
represents (for practical reasons) the number of samples since the start of=
the program.
Regards,
Raimund
Sorry i don't follow your thinking here. The sample count since midnight
idea in a BWF is to cover a 24hr period, if you aren't covering a single da=
y
then it isn't a BWF.
A 64bit int word surely gives plenty enough numbers for a 24hr period even=
if you are counting at 250k/sec. I think approx 2.E+10 is all that is req &=
|