10-29-2018, 05:38 PM
(This post was last modified: 10-29-2018, 05:40 PM by TheOldPresbyope.)
@Dig-It
It appears the root cause of our difficulties is that whatever tool was used to manipulate the metadata on the misbehaving .flac tracks encoded the wrong "magic number" in the first 4 bytes of the files.
The first 4 bytes of a FLAC file are specified to be Hex 66 4C 61 43 which is "fLaC" in ASCII.
For the files I previously identified as having odd properties, the first 4 bytes are Hex 49 44 33 03 which is "ID3^C" in ASII (where ^C represents the ASCII CTRL-C character). That "ID3" string is the specified header for an MP3 file with prepended ID3V2 metadata.
For some reason, the Xiph.org Audio metaflac tool I used doesn't flag this even though it is a tool from the very people who maintain the FLAC specification. Tim caught it in his own analysis (Yay, Tim!).
Using the Linux file command is an easy way to catch this. Where possible, the first part of its report is based on magic-number analysis.
For your FLAC files with the specified header, it reports "FLAC audio bitstream data..."
For what I'll call your "ID3" files, it reports "Audio file with ID3 version 2.3.0, contains: FLAC audio bitstream data..."
My position is that a FLAC-encoded file isn't a FLAC file if it doesn't have the specified header even if some software apparently ignores the contradiction. To me, it's perfectly proper for the Zend framework to enforce the specification.
I'm not sure there's a simple way to repair the files. My first attempt using dd to overwrite the first 4 bytes of one seemed to succeed syntactically but the resulting file wasn't recognized by the audio tools. I'll look into this further if I can find the time but no promises.
Regards,
Kent
It appears the root cause of our difficulties is that whatever tool was used to manipulate the metadata on the misbehaving .flac tracks encoded the wrong "magic number" in the first 4 bytes of the files.
The first 4 bytes of a FLAC file are specified to be Hex 66 4C 61 43 which is "fLaC" in ASCII.
For the files I previously identified as having odd properties, the first 4 bytes are Hex 49 44 33 03 which is "ID3^C" in ASII (where ^C represents the ASCII CTRL-C character). That "ID3" string is the specified header for an MP3 file with prepended ID3V2 metadata.
For some reason, the Xiph.org Audio metaflac tool I used doesn't flag this even though it is a tool from the very people who maintain the FLAC specification. Tim caught it in his own analysis (Yay, Tim!).
Using the Linux file command is an easy way to catch this. Where possible, the first part of its report is based on magic-number analysis.
For your FLAC files with the specified header, it reports "FLAC audio bitstream data..."
For what I'll call your "ID3" files, it reports "Audio file with ID3 version 2.3.0, contains: FLAC audio bitstream data..."
My position is that a FLAC-encoded file isn't a FLAC file if it doesn't have the specified header even if some software apparently ignores the contradiction. To me, it's perfectly proper for the Zend framework to enforce the specification.
I'm not sure there's a simple way to repair the files. My first attempt using dd to overwrite the first 4 bytes of one seemed to succeed syntactically but the resulting file wasn't recognized by the audio tools. I'll look into this further if I can find the time but no promises.
Regards,
Kent
