search for: thoulon

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...

...PICTURE block > in <http://xiph.org/flac/format.html>. Where did you read this? > METADATA_BLOCK_HEADER has a 24-bit field to encode the length of METADATA_BLOCK_DATA ; hence the limitation (which not only applies to METADATA_BLOCK_PICTURE but all metadata blocks. Pyt. -- Pierre-Yves Thoulon +33 (0)6 33 39 75 76 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20140620/a17dcae9/attachment-0001.htm

...ils at how the encoder works, but I think it is based on heuristics to decide which is the best compression method for a set of samples, and I'm not sure that it would give twice the same results for encoding the same file, although those results would be statistically similar... -- Pierre-Yves Thoulon On Wed, Mar 23, 2011 at 22:33, Brian Willoughby - brianw at sounds.wa.com <+flac-dev+pyt+81a7216403.brianw#sounds.wa.com at spamgourmet.com> wrote: > Hjalmar, > > I recall that many hardware decoders have a limit on the level that > they can handle. At the very least, hardwar...

Pierre-Yves Thoulon wrote: > None, apart from the standard metadata block size limitation (2^24 > bytes, e.g. 4GB). Pretty big for any kind of album art... 2^24 = 16777216, i.e. only 16 Megabytes. > Kind regards. > > Pyt. > > >> Le 10 mai 2017 à 17:11, Scott Brown - scottcbrown at gmail...

...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 whe...

Going in details through the FLAC format specification, I realize that there are 2 rice coding methods now supported for residual encoding. I thought I remembered in the 1.1.3 times that there was only 1 method (with 4-bit Rice parameter) [or was I drunk ? ;-)]. Going through the change log, I didn't find any reference to such an addition to the format. Now, the decoder implementation I'm

Dear members of the flac-dev list, I'm writing to ask for feedback from the FLAC community regarding the possibility of standardizing the FLAC specification through the Internet Engineering Task Force. I'm working with MediaArea on the PREFORMA project which focuses on building conformance checkers for Matroska and FFV1. Since Matroska and FFV1 are not yet formally standardized, this

I tried that approach a while ago and failed miserably. Marshalling the structs of structs in the flac lib turned out to be a nightmare (I don't pretend to be an expert, mind you...). I eventually switched to writing my own C# lib from scratch. Work is still under progress. It's no rocket science, I do this a G-job. It has definite limitations (no documentation, decodes only 16-bit files,

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

...#39;s( jcoalson ) reply on this thread is helpfull http://www.hydrogenaudio.org/forums/lofiversion/index.php/t57624.html my guess is u r not using 24 bit files thts why older decoder is able to decode it.. an then again not all 24 bit files will make use of that enhacement :) On 1/3/08, Pyt <py.thoulon@gmail.com> wrote: > > Going in details through the FLAC format specification, I realize that > there are 2 rice coding methods now supported for residual encoding. I > thought I remembered in the 1.1.3 times that there was only 1 method (with > 4-bit Rice parameter) [or was I drun...

is wrapping c++ any easier? because there is libFLAC++ otherwise, if you only need a certain subset of what FLAC does it might be easier to write a smaller C interface + wrapper implementation, then import that in c#. Josh --- Pyt <py.thoulon@gmail.com> wrote: > I tried that approach a while ago and failed miserably. Marshalling > the > structs of structs in the flac lib turned out to be a nightmare (I > don't > pretend to be an expert, mind you...). > I eventually switched to writing my own C# lib from scratch...

Is there any size limitation for album art? I have a user who says adding large artwork (from a scanner) is corrupting the file metadata. I don't know if this is a flac limitation, a tag lib issue, or something I'm doing. Thanks, Scott -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Thu, 19 Jun 2014 05:00:39 +0400 lvqcl <lvqcl.mail at gmail.com> wrote: >Erik de Castro Lopo wrote: > >> It sees that the most serious bug in the flac bug tracker: >> >> https://sourceforge.net/p/flac/bugs/413/ >> >> has been fixed in git. This fix alone is worth a new release so its >> time to work towards one. >> >> Things I need

I agree on everything you said. I did not intend or expect to have pre-release flac bundled with software, but can understand the dismay at my earlier request. If people think there should be a snapshot version for testing, I'm all for it, especially now that the build system has undergone some changes. I found that for some source distros, the removal of autogen.sh's prior features and

...o Lopo - mle+la at mega-nerd.com <flac-dev.pyt.682528eb7b.mle+la#mega-nerd.com at ob.0sg.net> wrote: > I'm currently looking to name it 1.3.0rc1. 1.3.0 because its been so > long since the last offical release and because of the change of > maintainership. > -- Pierre-Yves Thoulon +33 (0)6 33 39 75 76 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20130112/3845cd0c/attachment.htm

Hi, I'm developing a flac decoder in an embedded environment. I have it fully up and running but I am trying to optimise the performance vs. the power it takes to decode the stream. Using the reference decoder code with a few optimisations for the hw I'm on I experience quite a difference in mips depending on the level. For instance, on a 192kHz/24 bit file the difference is almost

Hello, everybody, Just in case you hit the wall, www.mjuware.com (home of FlacNetLib, FlacInfo and RipFlac) is temporarily out due to a change in domain name registration. Until this is fixed, the site is available at http://www2.mjuware.com Sorry for the inconvenience, Pyt. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Referring to my message of a couple of days ago, www.mjuware.com is back online. Sorry for the inconvenience. Pyt. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac/attachments/20140912/de5e7994/attachment.htm

Really sorry about this, www.mjuware.com is still unstable (thanks Jan for pointing this out). Please continue using the mirror at http://www2.mjuware.com for now. The situation should be fixed within a day or so (time for the information to propagate across DNSes around the world...). And sorry for polluting your intray... Kind regards, Pyt. -------------- next part -------------- An HTML

Hello, I have just released a set of FLAC utilities for Windows at http://www.mjuware.com The first one, FlacInfo, lets you play with metadata in a friendly way. The second one, RipFlac, is targetted at people who (like me...) store an entire CD in a single FLAC file with an embedded cuesheet. RipFlac lets you extract and transcode (using an external transcoder) tracks directly from the FLAC