TIMESTAMP_SAMPLES_SINCE_MIDNIGHT_HI

[Bouke]

What does it mean?
It's in Ixml (No clue what the 'i' means, intelligent it is not...)
Low is the start, Hi 'could' be the duration of the file, but that would be redundant as the Wave format already describes that, besides, I've NEVER seen a file that has another entry than zero.

 

 

[The Documentary Sound Guy]

It's a redundant listing of an equivalent BWF chunk apparently.  Here's the official explanation:

<TIMESTAMP_SAMPLES_SINCE_MIDNIGHT_HI> and <TIMESTAMP_SAMPLES_SINCE_MIDNIGHT_LO> is the same information included in the BWF fmt chunk - ie the declared WAVE sample rate, repeated here for convenience.

quoted from the official spec: http://www.gallery.co.uk/ixml/
 

I didn't dig further to find out what it means in the BWF spec, but since it is purely information in iXML, that explains why it is so commonly zero I think.

Based on the section it's defined it, it looks like it's related to off-speed clocking, which is a pretty unusual scenario.

[Wandering Ear]

I’m think the high word value is there to allow sample since midnight values larger than 32 bits. I have to run the numbers to see what value the crossover would be at, but I’m not sure a 48khz wav file would cross it in 24 hours which is why it’s generally always 0. 

[The Documentary Sound Guy]

Thanks for the eminently sensible explanation!

 

[Bouke]

I'm missing the joke, or the fact, either one...
(No clue why a string (as it is in XML) with an integer could have a 32 bit limit, as I can say 'a gazzilion times a billion plus the same times 1 million'. That is a string, would you like me to write it out as a 'one' (1) plus some zero's?
I can do you one better, press 1 on your keyboard, then press 0 and hold the key for a minute or so...

Copy / paste the result in your text editor.... (It will work just fine.)

 

[The Documentary Sound Guy]

Because iXML is just duplicating the values from the BWF chunk which, I presume, is an integer, not a string.

There are 48,000 x 60 x 60 x 24 = 4,147,200,000 clock ticks in a day at 48kHz, and an unsigned 32-bit value overflows at 4,294,967,296, so a 48kHz signal will never overflow.  But a 96kHz recording will overflow after 12.4 hours.

So, when represented in BWF, an extra integer, and therefore an extra data field is needed for sample rates above 48,000Hz.

[Wandering Ear]

7 hours ago, Bouke said:

I'm missing the joke, or the fact, either one...
(No clue why a string (as it is in XML) with an integer could have a 32 bit limit, as I can say 'a gazzilion times a billion plus the same times 1 million'. That is a string, would you like me to write it out as a 'one' (1) plus some zero's?
I can do you one better, press 1 on your keyboard, then press 0 and hold the key for a minute or so...

Copy / paste the result in your text editor.... (It will work just fine.)

 

 

You may get a string back when parsing the iXML data, but the value stored is in fact NOT a string.  Since it's a duplicate of the BWF metadata, the type is defined in the BWF spec.  It's a DWORD.  Look again at the spec for BWF files (page 10):

 

https://tech.ebu.ch/docs/tech/tech3285.pdf

 

DWORD is an old Microsoft / Windows construct, and I assume it was used here since Microsoft created the WAV and BWF specifications.  I admit I don't know the full history though.   Windows currently defines a DWORD as an unsigned 32bit integer.

 

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/262627d8-3418-4627-9218-4ffe110850b2?redirectedfrom=MSDN

 

A HIGH and LOW DWORD can be used to store numbers larger than 32 bits or to make up a QWORD (64 bit unsigned integer).  For numbers under 4294967295, the high word will always be 0

 

About half way down it touches on Microsofts WORD/DWORD/QWORD

 

https://en.wikipedia.org/wiki/Word_(computer_architecture)

 

 

I'll admit I have never been much of a windows  user / programer so I never worked with DWORD's directly.  I am interpreting it based on the specification.

 

[Bouke]

Aah, now I see.
I've always thought that Samples after midnight was 64 bit unsigned...

Thanks!

 

[Wandering Ear]

I honestly find the spec confusing.  Scrolling down further it lists a single TimeReference that is 64 bits, and that's what I've used in my software too.  I think it works correctly though because of how you combine the high and low words in bit order to make a 64 bit value.  I am not 100% sure about that though.

[Wandering Ear]

This discussion got me curious, and I never verified this in my own utilities so I ran a quick test.  I looked at 192Khz wav file with a TC around 23:00:xx:xx 

 

SSM: 15924465357 (larger than a 32 bit integer can handle)

 

The iXML High and Low values:

 

Looking at the raw file those bytes are represented by (in hex):

CD0E2CB5 03000000

 

Reading all 8 bytes and converting to unsigned int you get 15924465357

Reading the first 4 bytes and converting to unsigned int you get 3039563469

Reading the last 4 bytes and converting to unsigned int you get 3

 

So what did I learn?   You can't rely on only the _LO value if pulling TC from the iXML chunk.  You must convert both values into a single 64 bit value then convert to uint.  However you can read a 64 bit uint from the BEXT chunk if reading the raw file.

[Bouke]

So, the math for iXML. should be:
((Timestamp since mid HI * 4294967296 + Timestamp since mid LO) - 1) / samrate = TC as Seconds.
Mind the -1, as at least sound devices defines TC or Secs 0 as Sample 1...

The 4294967296 is of course 2 to the power of 32, max val of 32 bits.

Vice versa , floor(SSM /  4294967296) equals _HI
while SSM mod 4294967296 equals _Low

 

Agreed?

[Wandering Ear]

I don’t think you need to subtract 1, but otherwise  i think the math should work.  Might have to ensure you don’t use rounding when using division to calculate the HI value.  The way the spec is designed is to convert to raw byte arrays and concatenate / split then convert to integers, but the results should end up the same. 

[Bouke]

Well, I definitely think the -1 is needed to be utterly correct. TC 00:00:00:00 is SAM 1...
From SAM to TC it makes hardly ever any difference, but the other way around it does.
(Most of the time SAM to TC is only for human reference, an NLE will place a BWF on the timeline based on the SAM value, not on the calculated TC value, as that could be easily 20 msecs off...)
For the rounding, that's why I wrote 'Floor(SSM /  4294967296)'
Floor is pseudo code, in Python int() would work. ( int(12.9999) --> 12, at least in Python 3.something and higher )