Aleksander Korzynski wrote:
>> Some clarification of byte order, and conversion to floating point may
>> be necessary. As always, suggestions are welcome!
> So I think this is an open topic. Perhaps an integer value would be more
> reasonable, indeed.
If we decide to use an integer, then we have to think about the range of
> I also want to note that there actually should be two Peak values stored
> in a file: one for the given track, and one for the full album. They
> would be equivalents of the two ReplayGain values. Let's assume someone
> uses a ReplayGain-compatible player and increases the gain to make the
> track sound louder. At some point the player should warn that the Gain
> value is too high because it causes clipping. The warning should be
> displayed even if the current track doesn't clip, but some other track
> on the album does, because we can assume that the listener would listen
> to the rest of the album as well.
> Of course, the player could scan all the tracks on the album and find
> the maximum of all the peaks itself, but storing the maximum peak for
> the album will save that work.
> It doesn't say so in the standard, but it makes sense imo.
> Will there be some room in the header for the other peak value?
> At the moment Lame performs computations on a single file, so it
> wouldn't be used for now, anyway... but could be reserved for future.
I also think that it makes sense.
Btw it could be the right time for a refactor of the Lame tag. I would
like an easier tag, with less fields. Some of the current ones are imho
useless for an end user (like safejoint, noise shaping mode,...). Now
that we have some correct presets, I think that the preset value could
replace a lot of those fields.
personal page: http://gabriel.mp3-tech.org