<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi List!<br>On flac--l I was advised to cross-post to this list. So here is an extended version:<br><br><div><hr id="stopSpelling"><br><br>

<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}

.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}

--></style>
<div dir="ltr">After compiling opusenc.js to JavaScript [1], now the flac tool is also available [2][3], too.<br><br>s/Check out/Clone/ <a href="https://github.com/Rillke/flac.js" target="_blank">https://github.com/Rillke/flac.js</a> !<br><br>I
 am slightly nervous about its license, the GPL and what CloudFlare is 
doing: It's melting a lot of content together into one file (but not the flac tool's code which is loaded separately) and adding 
JavaScript that doesn't appear to be GPL or compatibly licensed -- by 
any chance, is there a possibility to get an exception (e.g. LGPL 
license) for JavaScript versions? It's also an issue to what happens in 
proprietary browsers, or more specifically in browsers with proprietary 
JavaScript VM, when they optimize code and insert custom assets. In 
theory, users of them can't abide with the licensing terms and use the 
tool online[5]. Advice welcome.<br><br>Another thing is the flac 
website[4] being GPL licensed, too. Of course one may quote from it; 
however things would be easier if it would be dual licensed, with 
something, say cc-by-sa 3.0 in addition.<br><br>Another issue that literally kills browsers is the static union of buffers in flac's src/flac/decode.c&nbsp; which is commented with "WATCHOUT: can be up to 2 megs" and this ends up as zero byte characters in a "memory initialization file" Emscripten creates[6]. This file is then, together with something else huge from analyze.c (I guess a variable of type "subframe_stats_t"), around 2.8 MiB. This is not a big deal for desktop browsers. GZIP compressed and quickly transmitted -- all no problem. But on mobile browsers, this causes them to run out of memory and they simply crash. Any idea how I could avoid that? Yeah, obviously I could drop decoding and analysing support (is there a command line switch for making the flac tool w/o decoding support btw?) ...&nbsp; looking for something that does not contain "drop support for" :)<br><br>Finally, thanks for the great free tools, Xiph.<br><br>-- Rillke<br><br>[1] <a href="http://lists.xiph.org/pipermail/opus/2014-December/002824.html" target="_blank">http://lists.xiph.org/pipermail/opus/2014-December/002824.html</a><br>[2] <a href="https://github.com/Rillke/flac.js" target="_blank">https://github.com/Rillke/flac.js</a><br>[3] <a href="https://blog.rillke.com/flac.js/" target="_blank">https://blog.rillke.com/flac.js/</a><br>[4] <a href="https://xiph.org/flac/index.html" target="_blank">https://xiph.org/flac/index.html</a><br>[5] <a href="http://stackoverflow.com/a/1239727/2683737" target="_blank"></a><a href="http://stackoverflow.com/a/1239727/2683737" target="_blank">http://stackoverflow.com/a/1239727/2683737</a><br>[6] <a href="http://kripken.github.io/emscripten-site/docs/optimizing/Optimizing-Code.html#very-large-projects" target="_blank">http://kripken.github.io/emscripten-site/docs/optimizing/Optimizing-Code.html#very-large-projects</a><br><br>                                               </div></div>                                               </div></body>
</html>