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

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>

Martijn,
> 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.
OK.

That's why I said

"as long as the audio data is consistent, with known format and 
correctly located."

However, I think there are relatively few uncompressed formats, and 
probably all of them share having large audio blocks. It would be 
feasible to think of an algorithm that attempts to find audio alignment 
by iteratively testing a short portion for different alignments (meaning 
different number of channels and bit depths, little/big endianness, and 
a few other variants or combinations of PCM) until the maximum 
compression is attained. Once located the optimum alignment, the FLAC 
algorithm would provide bit-for-bit accuracy and maximum compression, 
even in the absence of format-awareness. It would take a bit more time 
to encode and could generate its internal header for direct playback 
compatibility.

Regards,

Federico Miyara



-- 
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/20221103/112ec5f5/attachment.htm>