On Fri, Aug 26, 2016 at 09:58:47AM +0200, Anton Khirnov wrote: > Quoting Diego Biurrun (2016-08-26 09:48:26) > > On Thu, Aug 25, 2016 at 06:36:45PM -0500, Burt P. wrote: > > > On Thu, Aug 25, 2016 at 5:46 PM, Jean-Baptiste Kempf <j...@videolan.org> > > > wrote: > > > > On 25 Aug, Burt P. wrote : > > > >> HDCD coding is hidden in some CD audio, but not all, and using it is > > > >> completely optional. > > > > > > > > But you can detect that, cannot you? > > > > > > Yes, but it requires scanning the whole audio to know if you will be > > > using peak extend. > > > PE requires and 6dB of room at the top for the expanded peaks. > > > So you have to make two full passes, or just always apply -6dB to all > > > 16-bit audio in case HDCD/PE appears. > > > The current implementation does the latter, because we only get the > > > audio one frame of a few thousand samples at a time. > > > We need at least one or two seconds, 44100-88200 samples, to know we > > > will catch an HDCD packet. > > > There are some HDCD-CDs where only one track had HDCD encoding, > > > because it was a compilation or something. > > > In this case, you could have a single file flac+cue being processed, > > > and not know for 20 minutes into the audio that you need room for peak > > > extend. > > > > > > Audio players can scan ahead, and choose to use HDCD processing or not. > > > They can even enable-disable per track, or when seeking, by scanning > > > ahead or behind a couple seconds, without the listener noticing in > > > most cases. > > > For avconv/ffmpeg (at least the cli), however, I think it is best left > > > to the user. > > > > I'm with j-b on this one. If the filter is optional, it will be left > > out in 99% of cases. It sounds like you are optimizing for a rare edge > > case and sacrificing ease of use and better quality in 99% of cases for > > it... > > And do you have any practical suggestion about how this is to be > accomplished? As I understand, this kind of audio is incredibly rare, so > you cannot just impose a delay on all PCM decoding just because of the > tiny number of files that might need it. > > I can imagine a bitstream filter that would detect it and perhaps insert > appropriate side data signalling that the extra information is present, > but this is still awkward and fragile. > FWIW the filter approach seems acceptable to me.
Settled then. A filter it is. Diego _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
