flac dev - Dec 2018 - New ID registration

"Kurosawa, Taku" wrote:
> Hi Martijn,
>
> Sorry for the late reply again,
> The application we are preparing this time is not exactly similar to
> Replaygain.
>
> Replaygain as we understand is something which normalize the loudness at
> content provider side, but our application takes different approach. It is
> designed to normalize the loudness at player side, according to the
metadata
> embedded within the content, which could be relatively big in its size, so
> it will be unfit for Vorbis comment.
A VorbisComment can store upto 2^64 bytes
(16 exabytes).  A FLAC metadata block is
limited to 2^24 bytes (16 megabytes).
Therefore, a VorbisComment can be orders of
magnitude bigger than a FLAC metadata block.
Visit:
    https://wiki.xiph.org/Metadata

The advice to use a VorbisComment still looks
good.

Regards,
Martin
-- 
Martin J Leese
E-mail: martin.leese  stanfordalumni.org
Web: http://members.tripod.com/martin_leese/

On 12/11/18, Martin Leese <martin.leese at stanfordalumni.org> wrote:
> A VorbisComment can store upto 2^64 bytes
> (16 exabytes).  A FLAC metadata block is
> limited to 2^24 bytes (16 megabytes).
> Therefore, a VorbisComment can be orders of
> magnitude bigger than a FLAC metadata block.
> Visit:
>     https://wiki.xiph.org/Metadata
Rereading my post, I implied that a
VorbisComment inside a FLAC stream could
be larger than a FLAC metadata block.  As the
former must fit inside the latter (when inside a
FLAC stream), the limit for both is the smaller
of the two.
> The advice to use a VorbisComment still looks
> good.
This still looks good.

Regards,
Martin
-- 
Martin J Leese
E-mail: martin.leese  stanfordalumni.org
Web: http://members.tripod.com/martin_leese/

Hi Martin,

Apologies my reply being late again.
There might have been some mis-explanation from my side, so let me explain the
difference between Replaygain and our approach here.

- Replaygain
  The Gain calculation for the loudness normalization be done at content provide
side.
  The result will be embedded within the content as metadata.
  The Normalization will be done at player side, according to the gain embedded
within the content.

- Our approach
  Embed the binary data which reflect the character of the music within the
content at content provider side.
  The gain calculation for the loudness normalization will be done at player
side according to the binary data embedded within the content.
  The binary data could be used not only for the loudness normalization, but
also for something else in the future.

Our approach uses float format binary data block, which could be encoded to text
based metadata, but the process will be too complicated. It is not realistic
from technical point of view.
Also, since the Key_Name of Vorbis Comment is not unique based operated, if
other user uses same Key_Name as ours, that could result in in correct action
and that could ultimately lead us to suffer multiple losses in the service.

Hope I am explaining correctly the necessity of new ID registration here.

Taku
> -----Original Message-----
> From: flac-dev [mailto:flac-dev-bounces at xiph.org] On Behalf Of Martin
> Leese
> Sent: Wednesday, December 12, 2018 4:20 AM
> To: flac-dev at xiph.org
> Subject: Re: [flac-dev] New ID registration
> 
> On 12/11/18, Martin Leese <martin.leese at stanfordalumni.org> wrote:
> 
> > A VorbisComment can store upto 2^64 bytes
> > (16 exabytes).  A FLAC metadata block is limited to 2^24 bytes (16
> > megabytes).
> > Therefore, a VorbisComment can be orders of magnitude bigger than a
> > FLAC metadata block.
> > Visit:
> >     https://wiki.xiph.org/Metadata
> 
> Rereading my post, I implied that a
> VorbisComment inside a FLAC stream could be larger than a FLAC metadata
> block.  As the former must fit inside the latter (when inside a FLAC
> stream), the limit for both is the smaller of the two.
> 
> > The advice to use a VorbisComment still looks good.
> 
> This still looks good.
> 
> Regards,
> Martin
> --
> Martin J Leese
> E-mail: martin.leese  stanfordalumni.org
> Web: http://members.tripod.com/martin_leese/
> _______________________________________________
> flac-dev mailing list
> flac-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/flac-dev