similar to: mjuWare.com still not quite there

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:

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

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

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

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

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,

Hello, I have some Windows XP remote machines that need to connect to a VPN. Everything was working very well for more than a year. Last week one of this XP machines stop working. The service does not start at boot (I can start it manually). After manually starting it (services or tincd -n net) there is no traffic/ping. I have reinstalled the TAP interface. I have deleted and reinstalled the

Am 13.03.19 um 18:50 schrieb Rowland Penny via samba: > Try running 'samba-tool ldapcmp ldap://dc1 ldap://dc2' thanks! I get differences, too many to post here, but I assume mostly related to the drift between the 2 dcs now? (lastLogonTimestamp seems obvious to me) What might solve the initial problem *maybe* * Comparing [DNSFOREST] context... * Objects to be compared: 19

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:

Just set up postfix & it's running on my RHES 4.2 box. Immediately after postfix is up, I test sending emails from a permitted domain (ahhh, on this postfix server's domain firewall, we even have a firewall rule which permits Tcp25 from those few sending domains' SMTP servers) using an email client to sender_id@[IP_address_of_the_postfix_server] & the /var/log/maillog on