iXML calculation Errors on Drop Frame speeds.

filmo · Post by **filmo** » Fri Jan 03, 2014 8:58 pm

further on this thread: viewtopic.php?t=1039#p3803

I'm getting a discrepancy between calculated versions of the timecode string based on wether the format is drop frame or non-drop frame (23.976 and 29.97 being 'drop' and 24 and 30 being non-drop.). I suspect the error is the result of 'user error' on part of the sound engineer doing the recording and failing to set the DF/NDF flag correctly even though a DF speed has been selected.

In this parsed SPEED subnode, we see that the speed is 23.976... (24000/1001) yet the file is also marked NDF. This is 'not possible' since 23.976 is a 'drop frame rate'. Calling it NDF is nonsensical. (I'm surprised the recorder doesn't actually just automatically set this.) My feeling is that this flag should be ignored and the speed be used directly for calculating the timecode string.

Code: Select all

[SPEED] => Array
	(
		[NOTE] => Array
			(
			)

		[MASTER_SPEED] => 24000/1001
		[CURRENT_SPEED] => 24000/1001
		[TIMECODE_FLAG] => NDF
		[TIMECODE_RATE] => 24000/1001
		[FILE_SAMPLE_RATE] => 48000
		[AUDIO_BIT_DEPTH] => 24
		[DIGITIZER_SAMPLE_RATE] => 48000
		[TIMESTAMP_SAMPLE_RATE] => 48000
		[TIMESTAMP_SAMPLES_SINCE_MIDNIGHT_HI] => 0000000000
		[TIMESTAMP_SAMPLES_SINCE_MIDNIGHT_LO] => 3180201025
	)

I've created a secondary function and placed it in my audioinfo.class.php wrapper file it pulls both $this->info['riff']['WAVE']['iXML'][0]['timecode_rate'] and $this->info['riff']['WAVE']['iXML'][0]['timecode_string_round']. Get getID3 is correctly creating the SPEED, but not the timecode_string. Instead it is presenting the NDF calculation of the timecode rather than the DF version.

If you run my little snippet below, you get:

-- getID3 calculations --
timecode_rate = 23.976
ixml_timecode = 18:24:14:05
-- My code calculation --
tc = 18:23:08:00
speed = 23.976

I've opened the WAV file in Remetacator to confirm and my calculations are correct. At 24 fps, it calculates the TC as 18:24:14:04.1025 and at 23.976 it calculates the timecode as 18:23:08:00.1

Let me know what you think. If you like, I can PM you a link to the BWF file in question but I don't want to post it publicly. Thanks.

Code: Select all

private function parse_iXML() {
echo "<pre>";
        if (@$this->info['riff']['WAVE']['iXML'][0]['timecode_string_round']) {
            // see if there's an easily accessable frame rate and timecode string.
            $this->result['ixml_speed']        = sprintf("%3.3f",$this->info['riff']['WAVE']['iXML'][0]['timecode_rate']);
            $this->result['ixml_timecode']    = $this->info['riff']['WAVE']['iXML'][0]['timecode_string_round'];        
echo "timecode_rate = " . sprintf("%3.3f",$this->info['riff']['WAVE']['iXML'][0]['timecode_rate']) . "\n";
echo "ixml_timecode = " . $this->info['riff']['WAVE']['iXML'][0]['timecode_string_round'] . "\n";
        } 
        // manually calculate the timecode based purely on speed and samples, ignoring any DF/NDF flag.
        if (@$this->info['riff']['WAVE']['iXML'][0]['parsed']['SPEED']) {
            $iXML_ary = $this->info['riff']['WAVE']['iXML'][0]['parsed']['SPEED'];
            $speed_ary        = explode("/",$iXML_ary['MASTER_SPEED']);
            $sample_rate    = $iXML_ary['FILE_SAMPLE_RATE'];
            $time_samples    = $iXML_ary['TIMESTAMP_SAMPLES_SINCE_MIDNIGHT_LO'];
            
            // avoid divide by 0 errors in certain circumstances. Normally it should be 24/1 
            // or 24000/1001 for 23.976
            isset ( $speed_ary[1] ) ? $divisor =  $speed_ary[1]: $divisor = 1000;
            if ($divisor == 1) {
                $divisor *= 1000;
                $speed_ary[0] *=1000;
            }
            
            $master_speed    = round($speed_ary[0]/$divisor,4);

            $num_seconds    = (($time_samples / $sample_rate) * 1000)/$divisor;
            
            $tc_hour    = floor($num_seconds/3600); 
            $tc_minute    = floor(($num_seconds % 3600)/60);
            $tc_second    = $num_seconds  - $tc_hour * 3600  - $tc_minute * 60;
            
            $decimal_frames = $tc_second - floor($tc_second);
            
            $tc =     str_pad($tc_hour,2,'0',STR_PAD_LEFT). ":" . 
                    str_pad($tc_minute,2,'0',STR_PAD_LEFT) . ":" . 
                    str_pad(floor($tc_second),2,'0',STR_PAD_LEFT). ":" . 
                    str_pad(round($decimal_frames * $master_speed,0),2,'0',STR_PAD_LEFT);
echo "tc = $tc\n";
echo "speed = ". sprintf("%3.3f",$master_speed). "\n";
//            $this->result['ixml_speed']        = sprintf("%3.3f",$master_speed);
//            $this->result['ixml_timecode']    = $tc;
        } 
    }

Here's the full dump from getID3. I'm using getID3 1.9.7

Code: Select all

filmo · Post by **filmo** » Fri Jan 03, 2014 10:49 pm

My echo of "ixml_timecode" is from ['timecode_string_round']
(see code snippet.)

Post by **James Heinrich** » Sat Jan 04, 2014 12:12 pm

Please PM or email me a link to the file in question so I can replicate your testing.
Unfortunately I'm on the road right now and unable to do any getID3 testing or development for the next month, I will look at your file in early Feb 2014.

In the interim you can check that the behaviour is unchanged in the latest development version:
https://github.com/JamesHeinrich/getID3 ... e/1.10.zip
If you submit any patches it would be most useful against that version.

Post by **James Heinrich** » Wed Feb 19, 2014 9:06 pm

filmo wrote:If you like, I can PM you a link to the BWF file in question but I don't want to post it publicly.

I still haven't heard from you regarding the sample file. Please email or PM me a link to it.

It's hard for me to look at what's working / not working in your patch vs current getID3 code without the sample file.
As far as I can (quickly) see, getID3 does not use the DF/NDF flag in calculations, only the e.g. 24000/1001 rate.

If you can't send me a sample file to illustrate the problem, please edit your code into a patch against the current version of module.audio-video.riff.php (lines 417-441) as that would make it easier for me to see the changes you're suggesting.

getID3()

iXML calculation Errors on Drop Frame speeds.

Re: iXML calculation Errors on Drop Frame speeds.

Re: iXML calculation Errors on Drop Frame speeds.

Re: iXML calculation Errors on Drop Frame speeds.