METADATA_BLOCK_HEADER.BLOCK_TYPE (6) at offset 42 extends...

Locked
cbj4074
User
Posts: 10
Joined: Tue May 06, 2008 1:21 am

METADATA_BLOCK_HEADER.BLOCK_TYPE (6) at offset 42 extends...

Post by cbj4074 » Fri Sep 07, 2012 2:19 am

Hello,

Firstly, thanks to James, and to everyone else who contributes to this software and the community support effort.

Vitals are as follows:

- getID3 version: 1.9.3.
- PHP version: 5.4.3 (Windows 7 x86) (running via Apache's mod_php).
- The specific error message: "METADATA_BLOCK_HEADER.BLOCK_TYPE (6) at offset 42 extends beyond end of file" (the 42 may be arbitrary; I'm not sure).
- I haven't looked at the source code to try to determine the source of the error. I'm happy to expend the effort if the developers don't know the reason for this error off-the-cuff.

I've reviewed the list of known issues and the phrase "METADATA_BLOCK_HEADER" doesn't appear anywhere else on these forums (according to the Search feature, anyway).

I've used version 1.7.7 and 1.7.9, very successfully, for reading/parsing and tagging FLAC and MP3 files. But with version 1.9.3, there is a new error present when I attempt to tag FLAC files. (I never used 1.8.3 because it introduced a regression that affected me, related to tagging; for all I know, it could be this same issue!)

It's entirely possible that there has always been a problem with my files, but only recently did getID3 introduce an error (a "good thing", if so). Further, this error only occurs on some portion of files, not all of them. (All files are similar FLAC files; different audio tracks that are encoded with the same software and prepared in the same way.)

Here's the error message that getID3 emits:

Code: Select all

METADATA_BLOCK_HEADER.BLOCK_TYPE (6) at offset 42 extends beyond end of file
Is this some variant of a known issue? Perhaps this one?
All Ogg formats (Vorbis, OggFLAC, Speex) are affected by the problem of large VorbisComments spanning multiple Ogg pages, but but only OggVorbis files can be processed with vorbiscomment."?
But I'm not sure that this file is "OggFLAC"-encoded. The files with which this error occurs are FLAC files, encoded with libFLAC 1.2.1 20070917.

And it's not this, is it?
Known will-not-work:

ID3v1 tags (always located at end-of-file)
Nowhere in my code do I reference "id3v1", explicitly. And what's more, the same PHP code/logic used to function without issue (with version 1.7.9).

Thanks for any help! And please let me know if I can provide additional information.

James Heinrich
getID3() v1 developer
Posts: 1451
Joined: Fri May 04, 2001 4:00 pm
Are you a spambot?: no
Location: Northern Ontario, Canada
Contact:

Re: METADATA_BLOCK_HEADER.BLOCK_TYPE (6) at offset 42 extend

Post by James Heinrich » Fri Sep 07, 2012 2:47 am

Please email me a sample file that has this problem.

cbj4074
User
Posts: 10
Joined: Tue May 06, 2008 1:21 am

Re: METADATA_BLOCK_HEADER.BLOCK_TYPE (6) at offset 42 extend

Post by cbj4074 » Fri Sep 07, 2012 4:00 am

Thanks, James. Please check your PMs for a link to the file.

Another interesting point of note: this issue seems to occur only when there is cover artwork embedded in the FLAC file in question.

Equally interesting is that not all FLAC files in which cover artwork is embedded trigger this error message. So, the issue seems to result from a combination of factors.

I don't know if it's relevant, but I created the FLAC file in question by truncating a full-length file down to 10 seconds (which I do commonly during testing) using dBpoweramp. It's curious that the FLAC files for which this issue seems not to occur -- even when cover artwork is embedded -- were not truncated using dBpoweramp.

Even when truncated, tagging the FLAC files did not produce the error in question until I later added cover artwork and then attempted to re-tag the files.

James Heinrich
getID3() v1 developer
Posts: 1451
Joined: Fri May 04, 2001 4:00 pm
Are you a spambot?: no
Location: Northern Ontario, Canada
Contact:

Re: METADATA_BLOCK_HEADER.BLOCK_TYPE (6) at offset 42 extend

Post by James Heinrich » Fri Sep 07, 2012 11:57 am

cbj4074 wrote:Thanks, James. Please check your PMs for a link to the file.
PM not (yet?) received.

cbj4074
User
Posts: 10
Joined: Tue May 06, 2008 1:21 am

Re: METADATA_BLOCK_HEADER.BLOCK_TYPE (6) at offset 42 extend

Post by cbj4074 » Fri Sep 14, 2012 12:01 am

James, sorry to bug you (pardon the pun)!

If you haven't had a chance to take a look at that sample file, no problem. I just need to make a decision as to whether I should roll with 1.7.9 or wait for word on 1.9.3.

1.7.9 works reliably for my purposes, so I have no problem sticking with it.

Thanks again!

James Heinrich
getID3() v1 developer
Posts: 1451
Joined: Fri May 04, 2001 4:00 pm
Are you a spambot?: no
Location: Northern Ontario, Canada
Contact:

Re: METADATA_BLOCK_HEADER.BLOCK_TYPE (6) at offset 42 extend

Post by James Heinrich » Fri Sep 14, 2012 12:23 am

If I can ask for a couple days more, I'm just working through last-minute changes and bugfixes for 1.9.4-RC1 and I should have an answer for most of the outstanding issues (yours included) within the next few days.

James Heinrich
getID3() v1 developer
Posts: 1451
Joined: Fri May 04, 2001 4:00 pm
Are you a spambot?: no
Location: Northern Ontario, Canada
Contact:

Re: METADATA_BLOCK_HEADER.BLOCK_TYPE (6) at offset 42 extend

Post by James Heinrich » Fri Sep 14, 2012 6:53 pm

cbj4074 wrote:Here's the error message that getID3 emits:

Code: Select all

METADATA_BLOCK_HEADER.BLOCK_TYPE (6) at offset 42 extends beyond end of file
I tried looking at your sample file with v1.9.4 (current development version) and it worked fine. However, I also looked at it with v1.9.3 and it was also fine...

There have been a number of fixed in v1.9.4 that may affect this issue, so my suggestion for now would be to hold on for a couple more days until v1.9.4 is released (or email me to get a release candidate) and hopefully the issue is already fixed. If you try with 1.9.4 and still get the same error we can investigate further at that time.

Locked