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

Op do 3 nov. 2022 om 19:39 schreef Federico Miyara <fmiyara at
fceia.unr.edu.ar>:
>
>
> 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.
>
That would inevitably result in metadata getting stored as audio,
resulting in loud clicks and static, which I don't think is a good
idea.

I need uncorrupted metadata, as I use data in Base64 encoding in a long text tag
for my music synchronized light show. Implemented now in .mp3 ID3 tags, I hope
to extend to FLAC, but that only works if metadata is kept exactly in its
original content.

Scott Burkhart
Scott Burkhart Effects, LLC
http://www.scotteffx.com/
scott at scotteffx.com
https://www.linkedin.com/in/scotteffx
1-925-202-8852
> On Nov 3, 2022, at 8:10 PM, Martijn van Beurden <mvanb1 at gmail.com>
wrote:
> 
> ?Op do 3 nov. 2022 om 19:39 schreef Federico Miyara <fmiyara at
fceia.unr.edu.ar>:
>> 
>> 
>> 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.
>> 
> 
> That would inevitably result in metadata getting stored as audio,
> resulting in loud clicks and static, which I don't think is a good
> idea.
> _______________________________________________
> flac-dev mailing list
> flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.xiph.org/pipermail/flac-dev/attachments/20221103/6e96a6c7/attachment.htm>

Yes, adding a readily playable header may not be a good idea in the 
wrong hands and could be an option, but this method would allow 
compression of an audio file (or more generally, a signal file) with 
perfect recovery regardless of format or possible corruption.

Archiving corrupted or experimental files is a valid, albeit infrequent, 
usage case.

I'm aware that the raw format allows this but at the expense of the need 
of manual parameter input. In some cases, such as in adaptive sample 
rate (https://ieeexplore.ieee.org/document/1105415) the parameters may 
be unknown or meaningless. My proposal is to automatically estimate the 
needed information under the assumption that the file contains some sort 
of signal and possibly some ad hoc metadata.

Just in case somebody in the future might find this idea promising :).

By the way, I think a better name for "foreign metadata" would be 
"non-standard metadata" or "extended metadata"

Regards,

Federico Miyara


On 03/11/2022 16:09, Martijn van Beurden wrote:
> Op do 3 nov. 2022 om 19:39 schreef Federico Miyara <fmiyara at
fceia.unr.edu.ar>:
>>
>> 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.
>>
> That would inevitably result in metadata getting stored as audio,
> resulting in loud clicks and static, which I don't think is a good
> idea.
>
>


-- 
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/08da9fcd/attachment-0001.htm>