flac dev - Jan 2015 - FW: flac (encoder, analyzer, decoder) tool now (also) available in JavaScript‏

Hi List!
On flac--l I was advised to cross-post to this list. So here is an extended
version:






After compiling opusenc.js to JavaScript [1], now the flac tool is also
available [2][3], too.

s/Check out/Clone/ https://github.com/Rillke/flac.js !

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.

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.

Another issue that literally kills browsers is the static union of buffers in
flac's src/flac/decode.c  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?) ...  looking for something that does not contain
"drop support for" :)

Finally, thanks for the great free tools, Xiph.

-- Rillke

[1] http://lists.xiph.org/pipermail/opus/2014-December/002824.html
[2] https://github.com/Rillke/flac.js
[3] https://blog.rillke.com/flac.js/
[4] https://xiph.org/flac/index.html
[5] http://stackoverflow.com/a/1239727/2683737
[6]
http://kripken.github.io/emscripten-site/docs/optimizing/Optimizing-Code.html#very-large-projects

 		 	   		   		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/flac-dev/attachments/20150120/9b4524ba/attachment.htm

I'm not sure that I understand your goal. In a browser setting, I would
think that you want to decode a stream, not a file, because streaming should
have less of a memory impact. The reference decoder is a file decoder, so you
probably don't want to port that. I don't think that there is a
reference streaming decoder, so you'd need to write your own using the
libFLAC or libFLAC++ routines.

Brian

On Jan 20, 2015, at 10:14 AM, Rainer Rillke <rillke at wikipedia.de>
wrote:
> 
> After compiling opusenc.js to JavaScript [1], now the flac tool is also
available [2][3], too.
> 
> s/Check out/Clone/ https://github.com/Rillke/flac.js !
> 
> 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.
> 
> 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.
> 
> Another issue that literally kills browsers is the static union of buffers
in flac's src/flac/decode.c  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?) ...  looking for something that does not contain
"drop support for" :)
> 
> Finally, thanks for the great free tools, Xiph.
> 
> -- Rillke
>

Yeah, de-/encoding a stream would have a lot of advantages but there is no
streaming en-/ decoder I would be aware of and for the application I'd
intend to use it for, it might be sufficient to de-/ encode a file in whole.
Dependent of the time and efforts for creation and maintenance of a stream
encoder, it might not fit into the time budget. (Apart from that, as of now, it
gives a nice demo application that just runs quickly in every browser,
independently from any platform and has nearly zero maintenance cost.)

-- Rillke
> Subject: Re: [flac-dev] FW: flac (encoder, analyzer, decoder) tool now
(also) available in JavaScript?
> From: brianw at audiobanshee.com
> Date: Tue, 20 Jan 2015 10:25:31 -0800
> CC: flac-dev at xiph.org
> To: rillke at wikipedia.de
> 
> I'm not sure that I understand your goal. In a browser setting, I would
think that you want to decode a stream, not a file, because streaming should
have less of a memory impact. The reference decoder is a file decoder, so you
probably don't want to port that. I don't think that there is a
reference streaming decoder, so you'd need to write your own using the
libFLAC or libFLAC++ routines.
> 
> Brian
> 
> On Jan 20, 2015, at 10:14 AM, Rainer Rillke <rillke at wikipedia.de>
wrote:
>>...
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/flac-dev/attachments/20150120/3c2c1bbe/attachment.htm