similar to: Flac utilities released

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

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

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

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

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

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

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

I expect to release Ogg Frog 1.0 for public alpha test on Saturday, August 12. The date might slip a little depending on how my current job hunt goes; if I get a job sooner than I expect, I'll have to cut back on my development which has been full-time for a while now. The planned features are detailed at the page where the downloads will eventually be found:

I expect to release Ogg Frog 1.0 for public alpha test on Saturday, August 12. The date might slip a little depending on how my current job hunt goes; if I get a job sooner than I expect, I'll have to cut back on my development which has been full-time for a while now. The planned features are detailed at the page where the downloads will eventually be found:

Hello, I have used --import-cuesheet-from= to insert the cue points, which are OK according to "--export-cuesheet-to=-". The points I invoke are: - the possibility to specify them as frame count instead of time - the doc: i would not find in which format cue/seekpoints are stored in the headers - titles: apparently they get lost with this option. I guess they would be preserved if put