getID3's "analyze" method includes error after embedding art

[cbj4074]

Hello!

I'm not sure if this is a bug in getID3 or a bug in metaflac. Any help making that determination would be very much appreciated.

When I tag certain FLAC files using metaflac, and then call getID3's analyze() method on the resultant file, the result contains an error message and is missing all tag data:

Code: Select all

 ["error"]=>
  array(1) {
    [0]=>
    string(82) "METADATA_BLOCK_HEADER.BLOCK_TYPE (PICTURE) at offset 42 extends beyond end of file"
  }

Is metaflac somehow "butchering" the file? That seems somewhat unlikely, but possible, I suppose.

The full dump of the analyze() result is as follows:

Code: Select all

array(17) {
  ["GETID3_VERSION"]=>
  string(14) "1.9.9-20141121"
  ["filesize"]=>
  int(466068)
  ["filepath"]=>
  string(51) "/var/www/clients/client1/web5/private/protected/tmp"
  ["filename"]=>
  string(11) "NBizrA.flac"
  ["filenamepath"]=>
  string(63) "/var/www/clients/client1/web5/private/protected/tmp/NBizrA.flac"
  ["avdataoffset"]=>
  int(42)
  ["avdataend"]=>
  int(466068)
  ["fileformat"]=>
  string(4) "flac"
  ["audio"]=>
  array(10) {
    ["dataformat"]=>
    string(4) "flac"
    ["bitrate_mode"]=>
    string(3) "vbr"
    ["lossless"]=>
    bool(true)
    ["sample_rate"]=>
    int(44100)
    ["channels"]=>
    int(2)
    ["bits_per_sample"]=>
    int(16)
    ["bitrate"]=>
    float(372854.4)
    ["channelmode"]=>
    string(6) "stereo"
    ["compression_ratio"]=>
    float(0.26421088435374)
    ["streams"]=>
    array(1) {
      [0]=>
      array(9) {
        ["dataformat"]=>
        string(4) "flac"
        ["bitrate_mode"]=>
        string(3) "vbr"
        ["lossless"]=>
        bool(true)
        ["sample_rate"]=>
        int(44100)
        ["channels"]=>
        int(2)
        ["bits_per_sample"]=>
        int(16)
        ["bitrate"]=>
        float(372854.4)
        ["channelmode"]=>
        string(6) "stereo"
        ["compression_ratio"]=>
        float(0.26421088435374)
      }
    }
  }
  ["error"]=>
  array(1) {
    [0]=>
    string(82) "METADATA_BLOCK_HEADER.BLOCK_TYPE (PICTURE) at offset 42 extends beyond end of file"
  }
  ["encoding"]=>
  string(5) "UTF-8"
  ["mime_type"]=>
  string(12) "audio/x-flac"
  ["flac"]=>
  array(5) {
    ["STREAMINFO"]=>
    array(9) {
      ["min_block_size"]=>
      int(4608)
      ["max_block_size"]=>
      int(4608)
      ["min_frame_size"]=>
      int(3002)
      ["max_frame_size"]=>
      int(8247)
      ["sample_rate"]=>
      int(44100)
      ["channels"]=>
      int(2)
      ["bits_per_sample"]=>
      int(16)
      ["samples_stream"]=>
      int(441000)
      ["audio_signature"]=>
      string(16) "��/�*���0LG�f"
    }
    ["compressed_audio_bytes"]=>
    int(466026)
    ["uncompressed_audio_bytes"]=>
    int(1764000)
    ["compression_ratio"]=>
    float(0.26418707482993)
    ["encoding"]=>
    string(5) "UTF-8"
  }
  ["playtime_seconds"]=>
  int(10)
  ["md5_data_source"]=>
  string(32) "82eb022fde2a1118cdf6ec304c478f66"
  ["bitrate"]=>
  float(372854.4)
  ["playtime_string"]=>
  string(4) "0:10"
}

I can also provide the FLAC file and image that I'm embedding if that would be helpful!

Any insight into this problem would be great!

[James Heinrich]

Please provide a link to the sample FLAC with embedded image, either here or to info@getid3.org

[cbj4074]

Thank you, James! I just sent the files to info@getid3.org.

I just realized that I posted about the same issue in 2012:

viewtopic.php?t=1379

We never really got to the bottom of it back then.

The error message is exactly the same, and the error only happens with some files and not others (despite them all being prepared the same way), as described in my post from 2012. So, we may be dealing with the same issue.

When I posted the original thread, I don't think I realized that the error only occurred after embedding artwork into the file. I just tested this theory and indeed the problem seems to occur only once covert art has been embedded, which I am doing with the `metaflac` executable that is installed via the Ubuntu 12.04 repositories. For example:

Code: Select all

$ metaflac --import-picture-from="/tmp/cover.jpg" "/tmp/test.flac"'

metaflac version is "metaflac 1.2.1".

Please let me know if I can provide any additional information.

[cbj4074]

Just a heads-up that I received the following message when I included the getid3 domain in my post (in the link to the old thread):

The domain getid3.org you have posted has been blocked because it is blacklisted. For details please see [had to remove to be able to post].
An entry on the blacklist may have several reasons:
1. You are a well-known spammer.
2. Last time a well-known spammer was using the dynamic IP address which you got from your ISP (Internet Service Provider), your e-mail address or the username you have choosen.
3. Your ISP is well-known for a lot of spamming customers and is not fighting against spammers enough.

Somewhat humorously, including the error message in this post causes the same message about the ahbl.org domain.

Thought you should know, whether the message is accurate or not! :P

[James Heinrich]

ahbl.org is apparently shutting down and causing chaos by returning the blacklist flag for all queries rather than just keeping quiet.

[cbj4074]

Ahh, that's mighty courteous of them!

Back on-topic, I tried embedding a different image and the problem does not occur, so the particular image seems to be a factor.

It's entirely possible that I am testing with the same image now that I did in 2012 when last I raised this issue.

Curious to see what you find; thanks again for your willingness to look into this.

[James Heinrich]

The sample file you sent me does not generate any getID3 errors or warnings, at least using the current version of getID3 and demo.browse

[cbj4074]

Indeed you are correct, James.

My apologies; there are a lot of edits and iterations to this file and I'm trying to capture the correct state. Now, I'm checking the hashes and so forth and ensuring that I've "trapped" the correct issue before I send an updated file.

After all, it could be shoddy programming or operator-error, so I'll be sure to have a reproducible test-case when I reply.

Thanks again.

[cbj4074]

James,

I've tried hard to capture a file that will reproduce this error message, but if I issue an exit; statement immediately after the error occurs, and then feed the exact same file back into the analyze() method, the result is always error-free.

To elaborate, if I modify the getID3 source in module.audio.flac.php, so that the parseMETAdata() method looks like this (to include debug output and exit whenever this error condition is met), the name and hash of the file that throw the error are identical (according to the data stored in $info, which is equal to &$this->getid3->info) to the file and hash that I feed back into analyze() without error.

Code: Select all

	public function parseMETAdata() {
		$info = &$this->getid3->info;
		do {
			$BlockOffset   = $this->ftell();
			$BlockHeader   = $this->fread(4);
			$LBFBT         = getid3_lib::BigEndian2Int(substr($BlockHeader, 0, 1));
			$LastBlockFlag = (bool) ($LBFBT & 0x80);
			$BlockType     =        ($LBFBT & 0x7F);
			$BlockLength   = getid3_lib::BigEndian2Int(substr($BlockHeader, 1, 3));
			$BlockTypeText = self::metaBlockTypeLookup($BlockType);

			if (($BlockOffset + 4 + $BlockLength) > $info['avdataend']) {
				$this->error('METADATA_BLOCK_HEADER.BLOCK_TYPE ('.$BlockTypeText.') at offset '.$BlockOffset.' extends beyond end of file');
				
				var_dump('Block offset is: ' . $BlockOffset);
				var_dump('Arbitrary number is: ' . 4);
				var_dump('Block length is: ' . $BlockLength);
				var_dump('($BlockOffset + 4 + $BlockLength) is: ' . ($BlockOffset + 4 + $BlockLength));
				var_dump('$info[\'avdataend\'] is: ' . $info['avdataend']);
				var_dump('($BlockOffset + 4 + $BlockLength) > $info[\'avdataend\'] is: true');
				var_dump('File being analyzed is: "' . $info['filenamepath'] . '"');
				var_dump('SHA1 hash of above file is: ' . sha1_file($info['filenamepath']));
				
				exit;
				
				break;
			}
			if ($BlockLength < 1) {
				$this->error('METADATA_BLOCK_HEADER.BLOCK_LENGTH ('.$BlockLength.') at offset '.$BlockOffset.' is invalid');
				break;
			}
			
			//Remainder of function here...

This produces the following output:

Code: Select all

string 'Block offset is: 42' (length=19)

string 'Arbitrary number is: 4' (length=22)

string 'Block length is: 595326' (length=23)

string '($BlockOffset + 4 + $BlockLength) is: 595372' (length=44)

string '$info['avdataend'] is: 466068' (length=29)

string '($BlockOffset + 4 + $BlockLength) > $info['avdataend'] is: true' (length=63)

string 'File being analyzed is: "/var/www/clients/client2/web2/private/protected/tmp/6dbGQL.flac"' (length=89)

string 'SHA1 hash of above file is: 032910f63481cedfd09075e8e90b09c0b151c97d' (length=68)

Then, if I feed the same file, with the same hash, back into the analyze() method, like so, the result is error-free:

Code: Select all

$gid = new getID3();

$file = DOMAIN_ROOT . 'tmp/' . '6dbGQL.flac';

var_dump('Analyzing file "' . $file . '", with hash ' . sha1_file($file));

$r = $gid->analyze($file);

The output looks like this

Code: Select all

string(132) "Analyzing file "/var/www/clients/client2/web2/private/protected/tmp/6dbGQL.flac", with hash 032910f63481cedfd09075e8e90b09c0b151c97d"

and if I var_dump($r), the output looks perfectly fine and the error doesn't occur.

What could explain this behavior?

I'm not sure how else to narrow-down the condition that triggers this failure.

[James Heinrich]

That's kind of odd.

Perhaps it might reveal something if you put your debug dump info outside the if statement so that we can compare values between when the error is triggered in the first run and when it is not triggered in the second run.