flac dev - Feb 2012 - Meet the new maintainer

At 14:16 06.02.2012, you wrote:
>Olav,
>
>A change like this could easily break the format.  That would be a bad
choice.
That makes sense. Explains why it is not there today.

>On the other hand, an informational 'application' block could be
added in a way that does not break the format, and this would even be backwards
compatible since 'application' blocks have always been a part of the
specification.  You simply won't be able to rely on them being there.
This is probably the best thing then. Adding the info will be optional? It would
certainly be an improvement and hopefully become part of the command line
description so users would know how to do it.

Best regards

Olav Sunde

>Brian Willoughby
>Sound Consulting
>
>
>On Feb 6, 2012, at 03:16, Olav Sunde wrote:
>>This next is a feature request: Today it is not possible to know the
encoding of a flac archive. Many new devices support playback of flac, however
tiny processors sometimes have a hard time decoding files with the default
encoding of -5 or higher, resulting in unstable playback or even reduced audio
quality. A re-encoding to -0 often solve these issues.
>>Can you look at a way to store parameters used for encoding in an
archive so we can check it later?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/flac-dev/attachments/20120206/2ea6832a/attachment.htm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06.02.2012 18:52, Olav Sunde wrote:
> At 14:16 06.02.2012, you wrote:
> 
>> Olav,
>> 
>> A change like this could easily break the format.  That would be
>> a bad choice.
> 
> That makes sense. Explains why it is not there today.
> 
> 
>> On the other hand, an informational 'application' block could
be
>> added in a way that does not break the format, and this would
>> even be backwards compatible since 'application' blocks have
>> always been a part of the specification.  You simply won't be
>> able to rely on them being there.
> 
> This is probably the best thing then. Adding the info will be
> optional? It would certainly be an improvement and hopefully become
> part of the command line description so users would know how to do
> it.
> 
Make a specification for storing this kind of data in app-block, then
devise a way to measure encoding complexity of existing FLAC stream -
and you'll be able to put these block in FLAC files that didn't have
them originally.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPL/EaAAoJEOs4Jb6SI2CwBXgH/jaff2VYtoRfZEmU5iy5MXwT
lr/jDUkxgW11MLdXzZXk3Xwlg40iqPaE0Egn7Ie5SM2DgoVU52k7NrR6uC+U8Ii3
+cUp7EAH3bIRVrREeAPfhVUJiyCJSVmemBLPrRWRktaFeMBhw5K6wynG6lvQBTDm
Kj7m6F8H4JLMEI5PoTY/ur3L4/G4yZ++4jwTMNvicO8EljlLCdKVE6X+Ojb3kF7G
TkZyOsGZaSglETqkT8nZuVChq4DYSUcOX+MEeo3Ovdu1U6WefULw8VnFsqhL2yMU
OhRbo7+3+GzxHeMvF2Vo08smcA1BTThCiHCuZaYNmJ0n1Z86/xwk2xh8o4/CTM8=MRol
-----END PGP SIGNATURE-----

At 16:26 06.02.2012, you wrote:

>On 06.02.2012 18:52, Olav Sunde wrote:
>> At 14:16 06.02.2012, you wrote:
>> 
>>> Olav,
>>> 
>>> A change like this could easily break the format.  That would be
>>> a bad choice.
>> 
>> That makes sense. Explains why it is not there today.
>> 
>> 
>>> On the other hand, an informational 'application' block
could be
>>> added in a way that does not break the format, and this would
>>> even be backwards compatible since 'application' blocks
have
>>> always been a part of the specification.  You simply won't be
>>> able to rely on them being there.
>> 
>> This is probably the best thing then. Adding the info will be
>> optional? It would certainly be an improvement and hopefully become
>> part of the command line description so users would know how to do
>> it.
>> 
>Make a specification for storing this kind of data in app-block, then
>devise a way to measure encoding complexity of existing FLAC stream -
>and you'll be able to put these block in FLAC files that didn't have
>them originally.
This would be really useful. I hope someone will try to do this for the next
release of flac.

Olav
>_______________________________________________
>flac-dev mailing list
>flac-dev at xiph.org
>http://lists.xiph.org/mailman/listinfo/flac-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/flac-dev/attachments/20120207/06df756b/attachment.htm

On Mon, Feb 06, 2012 at 07:26:19PM +0400, lrn1986 at gmail.com
wrote:
> 
> Make a specification for storing this kind of data in app-block, then
> devise a way to measure encoding complexity of existing FLAC stream -
> and you'll be able to put these block in FLAC files that didn't
have
> them originally.
What we're looking for is a measure of the expected decoding complexity,
not the encoding complexity. The 2 are probably always going to be
closely related, but they are different things, and complexity will
depend on the data being compressed (aswell as on the encoder settings).

There was a request last year for something similar, so that an embedded
player using a CPU with adjustable clock speed (for power management)
can anticipate how much CPU power will be needed for the next track or
stream, before decoding begins. The idea being to adjust performance
(CPU or memory) in enough time to meet demand.

For known data (a music playlist using files, for example) the required
metadata could be stored on the playback device, ready for the next time
each track was played. For unknown data (streamed live audio) this would
not be much help.

-- 
-Dec.
---
"Mosaic is going to be on every computer in the world." - Marc
Andreessen, 1994