[Flac] playback problems with oppo BDP-95

[Brian Willoughby]

My friend somehow managed to get a BDP-95, even though the hardware
isn't scheduled to ship until March. The problem is that the manual
makes no mention of FLAC, at all, and only the web page claims to
support the format.

Playback of flac seems to work, but files from one online vendor work
flawlessly while files from other online vendors have strange
glitches that sound like a chirp or some kind of cheesy sci-fi movie
laser effect. My hunch is that the flac files with problems were
possibly compressed with --best or -8 and are just too much for the
BDP-95 to keep up with. Considering that the oppo BDP-95 supports
192 kHz playback and surround, I would expect them to use a fast
processor that can keep up with the demands of flac decoding.
Perhaps these problems will be fixed in the future with a firmware
upgrade - at least I hope it's not a situation where the processor is
simply underpowered and no amount of firmware rewriting will work.

I tried to browse around the main flac site looking for information
about hardware decoders, but I could not find any details. Has
anyone documented the levels of support for various pieces of
hardware? Actually, I see that the Squeezebox and Transporter are
specifically documented as supporting flac compression levels 0
through 8, which is great. Is there similar documentation of other
hardware platforms? I guess the BDP-95 is too new to be on any such
list anyway, but I was hoping to see more than three devices with
these details.

If anyone has suggestions, please let me know. I tried a couple of
Google searches, as well as Bing, but that was probably redundant.
Maybe I didn't use the right key words.

I'm suggesting that my friend uncompress to WAV and then recompress
with flac --fast, but I'm wondering if there is an easy way to know
that I higher level of compression would be guaranteed to work, even
for 'slow' hardware decoders.

Brian Willoughby
Sound Consulting

[Nicholas Wilson]

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
-----
Nicholas Wilson: nicholas at nicholaswilson.me.uk (ncw33)
Site and blog: www.nicholaswilson.me.uk
Peterhouse, CB2 1RD ? 86 Heath Road, GU31 4EL

Post by Brian Willoughby
My friend somehow managed to get a BDP-95, even though the hardware
isn't scheduled to ship until March. The problem is that the manual
makes no mention of FLAC, at all, and only the web page claims to
support the format.
Playback of flac seems to work, but files from one online vendor work
flawlessly while files from other online vendors have strange
glitches that sound like a chirp or some kind of cheesy sci-fi movie
laser effect. My hunch is that the flac files with problems were
possibly compressed with --best or -8 and are just too much for the
BDP-95 to keep up with. Considering that the oppo BDP-95 supports
192 kHz playback and surround, I would expect them to use a fast
processor that can keep up with the demands of flac decoding.
Perhaps these problems will be fixed in the future with a firmware
upgrade - at least I hope it's not a situation where the processor is
simply underpowered and no amount of firmware rewriting will work.
I tried to browse around the main flac site looking for information
about hardware decoders, but I could not find any details. Has
anyone documented the levels of support for various pieces of
hardware? Actually, I see that the Squeezebox and Transporter are
specifically documented as supporting flac compression levels 0
through 8, which is great. Is there similar documentation of other
hardware platforms? I guess the BDP-95 is too new to be on any such
list anyway, but I was hoping to see more than three devices with
these details.
If anyone has suggestions, please let me know. I tried a couple of
Google searches, as well as Bing, but that was probably redundant.
Maybe I didn't use the right key words.
I'm suggesting that my friend uncompress to WAV and then recompress
with flac --fast, but I'm wondering if there is an easy way to know
that I higher level of compression would be guaranteed to work, even
for 'slow' hardware decoders.
Brian Willoughby
Sound Consulting
_______________________________________________
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/20110206/e57783b7/attachment.htm

[Brian Willoughby]

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

Post by Nicholas Wilson
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

[Brian Willoughby]

On this note, is there any way to ask the current version of flac to
create a file that is backwards compatible with an older version of
flac? I suppose one possibility is to go back into the archives and
grab an older version of flac, then use that to compress everything.
The trouble then becomes how to determine which version of the
decoder your hardware implements, so that you can make sure your flac
files are not too "new" for the hardware.

Brian

Post by Brian Willoughby
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.

[scott brown]

Could it be metadata? Could the Oppo be scanning metadata before deciding
to play files?

Post by Brian Willoughby
On this note, is there any way to ask the current version of flac to
create a file that is backwards compatible with an older version of
flac? I suppose one possibility is to go back into the archives and
grab an older version of flac, then use that to compress everything.
The trouble then becomes how to determine which version of the
decoder your hardware implements, so that you can make sure your flac
files are not too "new" for the hardware.
Brian

Post by Brian Willoughby
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.

_______________________________________________
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/20110206/8db6d1e3/attachment.htm

[Pierre-Yves Thoulon]

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.

Post by Brian Willoughby
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

Post by Nicholas Wilson
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

[Nicholas Bower]

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.

Post by Pierre-Yves Thoulon
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.

Post by Brian Willoughby
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

Post by Nicholas Wilson
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

[Brian Willoughby]

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

Post by Nicholas Bower
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

Post by Pierre-Yves Thoulon
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...

[Pierre-Yves Thoulon]

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

Post by Brian Willoughby
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

Post by Nicholas Bower
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

Post by Pierre-Yves Thoulon
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