Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: FLAC APPLICATION metadata block (Read 3022 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

FLAC APPLICATION metadata block

Hey everyone,
has anyone been successful in adding files to flac's APPLICATION metadata block?
it would be very useful do embed a zip file containing all scans instead of adding multiple images on the PICTURE block.

I have found two apps that can do that, but they don't have a windows executable pre-compiled.
I created a repository for them, since the original site isn't available anymore:
https://github.com/bongmixtape/flac-image
https://github.com/bongmixtape/FlacFile

I've tried to compile them myself, but with no success.
If anyone could compile them for windows, I would be immensely grateful.

Re: FLAC APPLICATION metadata block

Reply #1
it would be very useful do embed a zip file containing all scans instead of adding multiple images on the PICTURE block.

What if the size of this .zip file exceeds 16 MBytes?

Re: FLAC APPLICATION metadata block

Reply #2
What if the size of this .zip file exceeds 16 MBytes?

That wouldn't be a problem.
for what I understand, this size limitation is only on the PICTURE metadata block, that each image can have a maximum of 16 Mb.
For the APPLICATION block, I couldn't find any limitation of size in the documentation

Re: FLAC APPLICATION metadata block

Reply #3
for what I understand, this size limitation is only on the PICTURE metadata block, that each image can have a maximum of 16 Mb.
For the APPLICATION block, I couldn't find any limitation of size in the documentation
Length field in METADATA_BLOCK_HEADER is 24 bit, so the 16 MB limit applies to all block types.

Re: FLAC APPLICATION metadata block

Reply #4
Length field in METADATA_BLOCK_HEADER is 24 bit, so the 16 MB limit applies to all block types.

Damn, that sucks.
It could still be useful though if you compress the scans. Some albuns can have a dozen or more images including the leaflet pages.
If you used webp compression for example, or even pdf's - it can save a lot of time being able to store any file extension.

Re: FLAC APPLICATION metadata block

Reply #5
If all you got are a bunch of pictures, then embed as art if you want anything to be able to read it.

If you want an attachment - like, a .pdf file that has value in its own right - then you might want to use some kind of container that can contain both the flac stream and the .pdf. You are trying to do this with flac's native container, but that is not a very compatible solution. Probably better are

* the file system's own container ... the directory. Cons: not well treated as "file".
(Let's not hack into alternative data streams eh?)

* .zip/.rar/.7z with the .flac and the .pdf. Cons: You need an audio player that can open an archive and look inside.

* check if for example Matroska gives you better luck. Cons: no flac file if you want flac.

 

Re: FLAC APPLICATION metadata block

Reply #6
If all you got are a bunch of pictures, then embed as art if you want anything to be able to read it.

If you want an attachment - like, a .pdf file that has value in its own right - then you might want to use some kind of container that can contain both the flac stream and the .pdf. You are trying to do this with flac's native container, but that is not a very compatible solution. Probably better are

* the file system's own container ... like a directory. Cons: not well treated as "file".

* .zip/.rar/.7z with the .flac and the .pdf. Cons: You need an audio player that can open an archive and look inside.

* check if for example Matroska gives you better luck. Cons: no flac file if you want flac.

I know that it's an unconventional solution, but I already tried all of the lossless formats, and although I admit that Matroska is the most flexible container, it's the worst, by far, to tag the files, do maintenance and compatibility.
Matroska uses xml for tagging and I've encountered all types of playback and metadata issues on different software and conversion to lossy formats to use on mobile while keeping the metadata is also a headache.