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