04-23-2019, 02:56 AM
Well, whether Valcun or Vulcan, I continued to be nagged by the apparent evidence that the metadata block of type APPLICATION was malformed and yet metaflac was able to remove it and leave a clean file. That seemed, er, "illogical, Captain".
I read the metaflac documentation more carefully and discovered one can force it to hexdump the application block's data contents rather than list it as text. When I do that with @kit1cat's files, the missing METADATA block line reappears. What seemed a 'smoking gun' before may have been nothing more than non-printing, binary bytes disrupting the output formatting.
I then went looking through all the FLAC files in my possession to see if any contained an application block. I found a whole album (HDtracks 2017 Hi-Res Sampler) which I'd downloaded at some point but never added to my NAS. All 15 track files contain full metadata including picture (coverart) and application blocks. Running metaflac --list --application-data-format=hexdump on these files properly lists all the blocks.
I added them to a directory on moOde's SDcard. I didn't get errors in moode.log when MPD scanned these files but I also don't get the coverart displayed in the playback panel.
If I then remove the application blocks from the files, as I described in my prior post, and update, the coverart does display.
At this point, I have to suspect the treatment of the application-block element by Zend.
@Tim Curtis - any thoughts about how best to go about tracing through the Zend_Media_Flac routines? I've read through all the FLAC-related code but PHP isn't my cup of tea. Just stick in test-probes like I see you've added in the past?
I'm tempted to write my own Python file-checker code to count bytes based on the xiph.org spec to confirm the files I have are legitimate as well as to make sure I understand the FLAC file structure well enough to critique the Zend code.
Regards,
Kent
I read the metaflac documentation more carefully and discovered one can force it to hexdump the application block's data contents rather than list it as text. When I do that with @kit1cat's files, the missing METADATA block line reappears. What seemed a 'smoking gun' before may have been nothing more than non-printing, binary bytes disrupting the output formatting.
I then went looking through all the FLAC files in my possession to see if any contained an application block. I found a whole album (HDtracks 2017 Hi-Res Sampler) which I'd downloaded at some point but never added to my NAS. All 15 track files contain full metadata including picture (coverart) and application blocks. Running metaflac --list --application-data-format=hexdump on these files properly lists all the blocks.
I added them to a directory on moOde's SDcard. I didn't get errors in moode.log when MPD scanned these files but I also don't get the coverart displayed in the playback panel.
If I then remove the application blocks from the files, as I described in my prior post, and update, the coverart does display.
At this point, I have to suspect the treatment of the application-block element by Zend.
@Tim Curtis - any thoughts about how best to go about tracing through the Zend_Media_Flac routines? I've read through all the FLAC-related code but PHP isn't my cup of tea. Just stick in test-probes like I see you've added in the past?
I'm tempted to write my own Python file-checker code to count bytes based on the xiph.org spec to confirm the files I have are legitimate as well as to make sure I understand the FLAC file structure well enough to critique the Zend code.
Regards,
Kent
