similar to: mjuWare web site

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:

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:

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

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

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

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

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

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

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

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

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:

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

I''ve corrected my HTDIG configuration so that it doesn''t fall into the symlink loop created by the 1.3 beta documentation. Sorry for any inconvenience, -Tom -- Tom Eastep \ Shorewall - iptables made easy AIM: tmeastep \ http://www.shorewall.net ICQ: #60745924 \ teastep@shorewall.net

Greetings! I thought I would take some time today to let you know about a wonderful new software package that will dramatically increase your web site's visibility. It's called The Spider, and I have been using it for several months and enjoyed a tremendous increase in my website's traffic. This software has impressed me so much that I decided to buy the reseller rights to it. And

Greetings! I thought I would take some time today to let you know about a wonderful new software package that will dramatically increase your web site's visibility. It's called The Spider, and I have been using it for several months and enjoyed a tremendous increase in my website's traffic. This software has impressed me so much that I decided to buy the reseller rights to it. And