Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Do all HDtracks.com aif files have four bytes of trailing nulls at end
06-11-2017, 18:51
Post: #1
Do all HDtracks.com aif files have four bytes of trailing nulls at end
Because of a problem reported by a customer I have downloaded two albums from hdtracks in aif format (Blur/Magic Whip, Green Day, American Idiot), in both cases there are 4 null bytes at the end of the file after the APPL chunk, that I don't believe should be there.

This causes a problem when editing because it confuses my file writing routine. Since this always writes ID3 to the end of the file AFTER the four bytes and it then becomes unreadable, in the original file the ID3 chunk is before the APPL chunk so is readable.

Is this extra 4 bytes evident throughout the HDTracks catalog, and am I right in thinking it is an error, (although even if it an error I will have to work round it).
Visit this user's website Find all posts by this user
Quote this message in a reply
06-11-2017, 19:14
Post: #2
RE: Do all HDtracks.com aif files have four bytes of trailing nulls at end
Are these 4 null bytes included in the form size? if not, MinimServer would never read these bytes as it stops reading at the end of the specified form size. I don't think it is an error to have extra data in the file following the form data.
Find all posts by this user
Quote this message in a reply
06-11-2017, 22:43
Post: #3
RE: Do all HDtracks.com aif files have four bytes of trailing nulls at end
(06-11-2017 19:14)simoncn Wrote:  Are these 4 null bytes included in the form size? if not, MinimServer would never read these bytes as it stops reading at the end of the specified form size. I don't think it is an error to have extra data in the file following the form data.

So for HDtracks the size recorded in the FORM chunk is 8 less then the end of the APPL chunk (the last chunk), then there are four null bytes after that (i.e difference to end of file is 12). In comparison for the files downloaded from Qobuz the size recorded in the FORM chunk is also 8 less than the end of the SSND chunk size. AFAIK QOBUZ is correct and size is size without including the 'FORM' and FORM size bytes, i.e 8bytes difference ?

So it does seem to be what you say, extra data after the form data length.

OKay I will have to make amendements to take that into account. Do you know of any cases where real data is put after the FORM size other than just null padding ?
Visit this user's website Find all posts by this user
Quote this message in a reply
06-11-2017, 22:52
Post: #4
RE: Do all HDtracks.com aif files have four bytes of trailing nulls at end
The length value in the FORM chunk header is 8 less than the total length of the FORM chunk (same for all chunks), so it sounds like the encoding is correct.

MinimServer never reads anything after the end of the FORM chunk and no users have reported a problem with this, so you should be safe to ignore anything after the end of the FORM chunk.
Find all posts by this user
Quote this message in a reply
07-11-2017, 00:20 (This post was last modified: 07-11-2017 00:24 by paultaylor.)
Post: #5
RE: Do all HDtracks.com aif files have four bytes of trailing nulls at end
(06-11-2017 22:52)simoncn Wrote:  The length value in the FORM chunk header is 8 less than the total length of the FORM chunk (same for all chunks), so it sounds like the encoding is correct.

MinimServer never reads anything after the end of the FORM chunk and no users have reported a problem with this, so you should be safe to ignore anything after the end of the FORM chunk.

Okay, thanks. It is effectively ignored when reading but causes problem when writing, I will change to get rid of it when writing

Just came across this from a few years ago http://forum.minimserver.com/showthread.php?tid=1454
Looks like initial complaint may have been same problem, although final part of thread is about a different issue.
Visit this user's website Find all posts by this user
Quote this message in a reply
07-11-2017, 08:01
Post: #6
RE: Do all HDtracks.com aif files have four bytes of trailing nulls at end
The problem decribed in the first part of this other thread is similar in some repects but also seems to have the form size set incorrectly (so that it includes the "garbage" characters).
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)