flac dev - Nov 2022 - Looking for users of --keep-foreign-metadata

Considering that

1) audio data is always (I believe...) in a single connected block,
2) its location and length is unambiguously known,
3) its basic formatting information is at the header, hence readily and 
unambiguously known, and
4) all metadata, either native or foreign, including the header, is 
before or after the audio data (or both),

would it be very difficult to just store all the information before and 
after the audio, even compress it with any content-unaware algorithm 
such as LZW, compress the audio with FLAC's algorithm and when decoding 
restore each block (pre-audio metadata, audio, and post-audio metadata) 
at its correct location?

This would provide bit-for-bit accuracy, even for inconsistent or 
ill-formed metadata, as long as the audio data is consistent, with known 
format and correctly located.

I don't know whether this would cause backward-compatibility issues, 
probably yes.

Regards,

Federico Miyara


On 02/11/2022 09:48, Martijn van Beurden wrote:
> Op ma 31 okt. 2022 om 01:37 schreef brianw <brianw at
audiobanshee.com>:
>> - There is a generally-accepted industry practice concerning these
extra chunks that points out that it's problematic to preserve all types of
chunks when editing the audio. For example, a visual overview or a cue list
might easily become incorrect if the audio is changed. Of course, there are some
chunks that can always be preserved, like original recording date, name of
engineer, etc., but FLAC cannot know how to distinguish between the two types.
My opinion is that FLAC should not suffer from this category of issues because
the audio is specifically unchanged by the compression. Thus, it should be the
case that all meta data can be preserved without risk, since the audio is also
preserved exactly.
>>
> Perhaps FLAC should refuse to do operations like --skip or --until on
> a file with foreign metadata embedded? I don't think it blocks that
> currently.
>
> What I think would be a nice option is pick the correct format
> according to the stored foreign metadata. Currently, one can use flac
> --keep-foreign-metadata somefile.aiff without problems, but flac
> --keep-foreign-metadata somefile.flac will then fail because flac
> tries to restore to wav by default. Also, there are the mentioned
> problems with WAVE_FORMAT_PCM and WAVE_FORMAT_EXTENSIBLE. One possible
> solution is adding an option --force-foreign-metadata-format (similar
> to the --force-aiff-format, --force-rf64-format, etc. options) which
> would then pick a format according to what is stored in the foreign
> metadata. This could work two ways: it could simply instruct FLAC to
> find which format should be written to, or it could instruct FLAC to
> not construct any chunks of its own but exclusively use the stored
> chunks.
>
>> Reading your email question, Martijn, I think you might be asking
whether FLAC should always preserve meta data - "restore ... bit-for-bit
... something that FLAC should strive for" - or leave this as an optional
feature, so I want to comment on the two scenarios:
>>
> Considering being bit-for-bit accurate, I might be opening Pandora's
> box here, but I think this should be dealt with properly, so I'll do
> it anyway
>
> The thing is, FLAC will store all chunks (except the contents of the
> data chunk) on encoding, but currently ignores the master chunk, the
> format chunk and the header of the data chunk on decoding. Usually the
> result is still bit-for-bit the same (because there is usually no
> ambiguity in how those chunks are formatted) but perhaps (I really
> don't know, don't know whether such a thing is even possible) there
> are cases where FLAC reconstructs something different than what is
> stored. Choosing between WAVE_FORMAT_PCM and WAVE_FORMAT_EXTENSIBLE is
> one such difference, but there might be others. That is why I'm
> reaching out: perhaps the answer is obvious to people that use this
> feature daily.
>
> Perhaps an option --force-stored-foreign-metadata could be added to
> have FLAC blindly use the foreign metadata chunks and data chunk
> headers. I think this might result in invalid files (wrong chunk
> sizes) in corner cases, for example when a FLAC file has been altered
> (shortened/lengthened) but the chunks haven't been updated. I think
> that might be the reason for the current behaviour.
>
>> p.p.s. AIFF
>> I cannot remember whether --keep-foreign-metadata works with AIFF
> Yes, it does. It works with plain WAV and AIFF, and also with RF64 and
Wave64.
> _______________________________________________
> flac-dev mailing list
> flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
>


-- 
El software de antivirus Avast ha analizado este correo electr?nico en busca de
virus.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/flac-dev/attachments/20221102/b9ea29ef/attachment-0001.htm>

Op wo 2 nov. 2022 om 21:44 schreef David Willmore <davidwillmore at
gmail.com
>:
>
> If a --force-* option fails, shouldn't it error out instead?  Scripts
aren't going to pick up on a warning, but they should pick up on an errored
exit code (or they're just not written well enough to
care).
>
I wasn't referring to that force option, that is only for picking a format.
The warning would be paired with --keep-foreign-metadata on decoding.

Op wo 2 nov. 2022 om 21:54 schreef Federico Miyara <fmiyara at
fceia.unr.edu.ar
>:
>
> Considering that
>
> 1) audio data is always (I believe...) in a single connected block,
> 2) its location and length is unambiguously known,
> 3) its basic formatting information is at the header, hence readily and
> unambiguously known, and
> 4) all metadata, either native or foreign, including the header, is before
> or after the audio data (or both),
>
> [...]
>
> This would provide bit-for-bit accuracy, even for inconsistent or
> ill-formed metadata, as long as the audio data is consistent, with known
> format and correctly located.
>
Currently FLAC already stores and restores most kinds of metadata
corruption without problems, so in most cases the conversion is already
bit-accurate. However, there are some kinds of corruption it cannot handle.
These are the kinds of corruption that invalidate your considerations. For
example, when a chunk length is incorrect, the location and length of the
audio data is no longer known. It is also possible the basic formatting
information is invalid. In this case, FLAC cannot compress the audio at
all, not even without considering foreign metadata, while general purpose
compressors (who don't have to discriminate between audio and metadata)
have no problem compressing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/flac-dev/attachments/20221103/244a014c/attachment.htm>