Op do 3 nov. 2022 om 20:17 schreef Scott Burkhart :
>
> 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
Hi,
I'm using this features to keep specific wav/aiff chunk like the one
that store loop information
for sampler instrument purposes.
Works fine as is.
Regards,
Le 30/10/2022 à 15:06, Martijn van Beurden a écrit :
Hi all,
Currently I'm looking for users of the --keep-foreign-metadata feat
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 experiment
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
Op do 3 nov. 2022 om 19:39 schreef Federico Miyara :
>
>
> 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 a
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. F
Op wo 2 nov. 2022 om 21:44 schreef David Willmore :
>
> 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
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
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).
On Wed, Nov 2, 2022 at 2:20 PM Martijn van Beurden wrote:
> Op wo 2 nov. 2022 om 13:48 sc
Op wo 2 nov. 2022 om 13:48 schreef Martijn van Beurden :
> 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
Op ma 31 okt. 2022 om 01:37 schreef brianw :
> - 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 inco
On Oct 30, 2022, at 10:21 PM, Federico Miyara wrote:
>> - 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
>> easil
- 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 ar
I use this feature whenever archiving audio files created by specific hardware,
where the metadata might be important to retain for the future. There are also
specific software examples where added metadata is important to preserve.
I have not looked into the details, so I can't give an opinion
Op zo 30 okt. 2022 om 19:05 schreef Federico Miyara :
> The feature works properly most of the time. The only exception is when one
> tries to decode, enabling the feature, something that hasn't been encoded
> enabling the feature (for instance, if when encoding I forgot enabling it).
> In that
Martijn,
I'm a user of the feature. My case usage is the following; I record
speech and music with a digital recorder (Zoom H4n) which uses a special
wav format version including BEXT information, a kind of metadata
including, for instance the device used to create the wav file. As I
then proces
16 matches
Mail list logo
