similar to: Temporary outage of mjuware.com

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

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

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

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

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

I seem to recall that changes in the second number indicated a minor change in the *format* of the file itself (for example, 1.1.x to 1.2.x introduced a new rice coding option used for 24-bit files). Are there any format changes that would justify that ? Otherwise, 1.2.2 would seem more appropriate, not to minimize the work that you are doing... Cheers, Pyt. http://www.mjuware.com On Sat, Jan

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.com >> <flac-dev.pyt.8c0cc6600b.scottcbrown#gmail.com at

I would also add that the "level" is only relevant to the reference encoder, as it is an alias to quickly set a number of parameters. Other encoders might make different choices. Also, I haven't looked in details 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

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

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

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,

yeah the chnage is not entered in the change log.. it helps in achieving better compression for 24 bit files.. an i think it came in as a mistake cvs merge in 1.2.1 encoder .. neways i think Josh'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

On Fri, Jun 20, 2014 at 1:05 AM, lvqcl <lvqcl.mail at gmail.com> wrote: > I cannot find anything about the size of METADATA_BLOCK_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

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

FlacNetLib was by far the most useful code reference. if you dont know object oriented programming then you need to muddle through libFLAC as i havent seen any other implementation that isnt OO. -Gravis On Sun, Nov 4, 2012 at 1:16 PM, Serban Giuroiu <giuroiu at gmail.com> wrote: > Hi, Gravis. > > I'm trying to build a FLAC encoder from scratch. Besides the official format

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

FlacNetLib was by far the most useful code reference. if you dont know object oriented programming then you need to muddle through libFLAC as i havent seen any other implementation that isnt OO. -Gravis On Sun, Nov 4, 2012 at 1:16 PM, Serban Giuroiu <giuroiu at gmail.com> wrote: > Hi, Gravis. > > I'm trying to build a FLAC encoder from scratch. Besides the official format

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

Hi Harry I attach you FLACInfo C# class and also for the forum. I already added frames number code. Code for VORBIS Tags is not included . But taking as sample the code for Vendor and following the specifications you can make it easily.With a loop similar to Vendor you can read all Tags. It's only necessary to keep in mind two things: VORBIS is litteleendian and FLAC doesn't use the

The initial rule was, if I can recall correctly : - Changes in the first digit (e.g. 1.x.x to 2.x.x) indicate a break in backwards compatibility ; i.e. the formats are totally different. - Changes in the second digit indicate backward-compatible changes in the format (i.e. a 1.1.x-encoded file is only a particular case of a 1.2.x-encoded file) - Changes in the third digit reflect any other,