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). |
|||
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.
|
|||
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 ? |
|||
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. |
|||
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. 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://forum1613.minimserver.com/showthr...p?tid=1454 Looks like initial complaint may have been same problem, although final part of thread is about a different issue. |
|||
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).
|
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)