Version 1.2.1 of the standard/spec or the local implementation? I've not seen "FLAC 1.0/1.1 Compliant" or "FLAC 1.2 Compliant" on the specs of hardware gear for example when FLAC is stated supported. Just a curious on-looker. On 7 February 2011 02:34, Pierre-Yves Thoulon <py.thoulon at gmail.com> wrote:> Version 1.2.1 introduced new rice coding techniques that are used by > the reference encoder for 24 bit files. An older version of the > decoder will have trouble with frames that use this encoding... Maybe > that's where the strange noises come from... > > Pyt. > > On 6 f?vr. 2011, at 06:01, Brian Willoughby <brianw at sounds.wa.com> wrote: > > > Thanks for bringing up this aspect, Nicholas. I seem to recall that > > specific hardware has a problem with certain compression levels, but > > I cannot recall whether that was limited to just encoding, or > > decoding as well. It could very well be true that I am conflating my > > vague memory of encoder limitations with decoder limitations. > > > > It does seem to be that the oppo BDP-95 is exhibiting problems with > > particular flac files. Since my original message, my friend has > > installed the latest version of flac and recompressed the exact files > > that were giving him a problem before - now with -0 or --fast he > > doesn't see a playback problem at all. So, even though your > > statements make total sense to me, the evidence seems to indicate > > something about the compressed data that's causing a problem. The > > original audio is not the issue, but how it is compressed. > > > > Here's a thought: Since the encoder looks for polynomials, could it > > be possible that certain decoders cannot handle certain polynomials > > in real time? > > > > Ah, another possibility is that the oppo BDP-95 implements an older > > version of the decoder, and it's merely new flac files that give it a > > headache. My friend happened to have an old version of flac > > installed on his computer, 1.1.4, and that reported stream errors > > with his files until he upgraded to 1.2.1 - if the oppo has anything > > older than 1.2.1 then I suppose that might explain the decoding > > problems. > > > > Brian > > > > > > On Feb 5, 2011, at 16:33, Nicholas Wilson wrote: > >> Correct me if wrong, but I was under the impression that the > >> processing required for playback was totally independent on the > >> level of compression. The encoder looks for polynomials that fit, > >> and it takes much more processing to find polynomials with a very > >> good fit and small residuals. On the other hand, the decoder just > >> has to multiply out the stored prediction, which is independent of > >> the compression level. > >> > >> Nicholas > > _______________________________________________ > > Flac mailing list > > Flac at xiph.org > > http://lists.xiph.org/mailman/listinfo/flac > _______________________________________________ > Flac mailing list > Flac at xiph.org > http://lists.xiph.org/mailman/listinfo/flac >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac/attachments/20110207/f338d583/attachment.htm
What is a "local implementation?" Do you mean the hardware version number? I think Pierre-Yves may be correct. There certainly were some changes to 24-bit support, and many of these problematic FLAC files are HD audio. In other words, they're not simply 16-bit 44.1 kHz CD audio converted to FLAC, but they are 24/96 or 24/192 audio in FLAC format. The only curious thing is that using flac 1.2.1 with --fast or compression level 0 is enough to make the hardware happy. In that case, are only the old Rice codings used for lower compression levels with 24-bit audio? You raise a good point, Nicholas. I would like to see manufacturers give specific information about what level of the FLAC format they support. The BDP-95 does not mention FLAC in the manual at all, and the web page only mentions FLAC twice - once in a bold heading, and again in the body of text. Neither mention of FLAC gives any details at all - they just put it in the list of formats. I suppose, in comparison, that MP3 players usually don't give any details about whether the hardware supports 320 Kb or multichannel or anything else. Perhaps we're reaching an age where nobody cares about the details. Brian Willoughby Sound Consulting On Feb 6, 2011, at 15:24, Nicholas Bower wrote:> Version 1.2.1 of the standard/spec or the local implementation? > > I've not seen "FLAC 1.0/1.1 Compliant" or "FLAC 1.2 Compliant" on > the specs of hardware gear for example when FLAC is stated supported. > > Just a curious on-looker. > > > On 7 February 2011 02:34, Pierre-Yves Thoulon > <py.thoulon at gmail.com> wrote: >> Version 1.2.1 introduced new rice coding techniques that are used by >> the reference encoder for 24 bit files. An older version of the >> decoder will have trouble with frames that use this encoding... Maybe >> that's where the strange noises come from...
Actually, I checked my archives, it's 1.2.0 which introduced the additional scheme for rice coding, not 1.2.1, but that doesn't change the gist of it... I remember seeing a note from Josh a long time ago, saying that those new encodings were only for 24-bit files. I has never seen these on standard 16-bit CD-rip type FLACs, but I found them in the first 24-bit file I was confronted with (a simple 24/44.1 file). It may very well be that the low-effort compression doesn't bother using these. -- Pierre-Yves Thoulon On Mon, Feb 7, 2011 at 01:51, Brian Willoughby <brianw at sounds.wa.com> wrote:> What is a "local implementation?" Do you mean the hardware version > number? > > I think Pierre-Yves may be correct. There certainly were some > changes to 24-bit support, and many of these problematic FLAC files > are HD audio. In other words, they're not simply 16-bit 44.1 kHz CD > audio converted to FLAC, but they are 24/96 or 24/192 audio in FLAC > format. > > The only curious thing is that using flac 1.2.1 with --fast or > compression level 0 is enough to make the hardware happy. In that > case, are only the old Rice codings used for lower compression levels > with 24-bit audio? > > You raise a good point, Nicholas. I would like to see manufacturers > give specific information about what level of the FLAC format they > support. The BDP-95 does not mention FLAC in the manual at all, and > the web page only mentions FLAC twice - once in a bold heading, and > again in the body of text. Neither mention of FLAC gives any details > at all - they just put it in the list of formats. I suppose, in > comparison, that MP3 players usually don't give any details about > whether the hardware supports 320 Kb or multichannel or anything > else. Perhaps we're reaching an age where nobody cares about the > details. > > Brian Willoughby > Sound Consulting > > > On Feb 6, 2011, at 15:24, Nicholas Bower wrote: > > Version 1.2.1 of the standard/spec or the local implementation? > > > > I've not seen "FLAC 1.0/1.1 Compliant" or "FLAC 1.2 Compliant" on > > the specs of hardware gear for example when FLAC is stated supported. > > > > Just a curious on-looker. > > > > > > On 7 February 2011 02:34, Pierre-Yves Thoulon > > <py.thoulon at gmail.com> wrote: > >> Version 1.2.1 introduced new rice coding techniques that are used by > >> the reference encoder for 24 bit files. An older version of the > >> decoder will have trouble with frames that use this encoding... Maybe > >> that's where the strange noises come from... > _______________________________________________ > Flac mailing list > Flac at xiph.org > http://lists.xiph.org/mailman/listinfo/flac >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac/attachments/20110207/f411954c/attachment.htm