
FLAC Support in Firefox 51 - kawera
https://bugzilla.mozilla.org/show_bug.cgi?id=1195723
======
captainmuon
The wierd thing is that this has been supported for years. Firefox has a
compile-time flag that allows it to use operating system codecs, it is just
not activated in the official binaries. (I think it also uses a codec
whitelist on some OSes, and you have to comment out a line.) On Windows, it
used DirectShow codecs, on Linux GStreamer, and on OS X probably quicktime.
It's great to be able to just point the browser to a file on the local net and
be able to play everything the system can play (and even if it couldn't load
the system codec, it could load a MPlayer plugin).

I used this for a while on Linux when there was a codec war between Firefox
and Chrome (forgot the details), but I could play videos that normally only
played in Chrome without problems.

Browser vendors cite usability problems (if one person's browser supports more
codecs than the default, then it is confusing for other people with the
default browser... and the person with more codecs might create websites that
depend on this), and stability problems (plugins in any form have a bad
reputation, but actually the default OS media player codecs are of pretty good
quality as they are excercised thoroughly). But honestly, I think it is mostly
politics that this is not enabled.

~~~
acdha
One big concern is security: code like this is notoriously prone to exploits
and once shipped everyone is exposed whether or not they use it.

That doesn't mean new formats can't happen but it should encourage some
careful assessment of the benefits relative to the need to support it for
years.

(This is one of the stated reasons why Firefox never shipped JPEG 2000 support
despite some demand)

~~~
captainmuon
True, but there is no intrinsic reason why code from one vendor (Mozilla,
Chrome group at Google) should be more or less secure that from the OS
developer (e.g. MS, Apple).

In fact, for probably everybody except large browser vendors, you should never
roll your own codecs (security, networking libs...) if it is not absolutely
necessary.

~~~
zeta0134
I disagree with this idea in the specific domain of Web Browsers. If a
vulnerability is discovered in a codec that ships with Firefox, Mozilla can
have a patch out within 24 hours. They only have to test that codec against
their own browser software.

Microsoft and Apple _can technically_ roll out a similar patch within 24
hours, but will rarely do so except for major bugs, which have significant
baby-punching abilities, as they have to test all of the rest of the operating
system software against changes to system libraries. (Linux users get to
update their libraries independently, so my argument doesn't really hold water
there.)

Since my web browser is one of those bits of software that I regularly expect
to load code that I will not vet, from developers whom I don't necessarily
trust, I feel like I'd rather have it loading codecs that were designed with
the web in mind. I don't think I trust it running my OS codecs, especially for
more complicated formats.

This still doesn't mean I'd expect Mozilla to write their own codecs from
scratch; certainly they should pull that codec in from an open source, well
written and well supported library. But I think they're in a better position
to respond to threats and patch domain-specific issues out of that library
than my OS vendor is.

------
niftich
Finally!

I wonder why this took so long. The assumption that no sane site would want to
stream in lossless when lossy codecs were starting to be really good (and
obviously much smaller)? Lack of expertise, manpower? Priorities? [1][2] Does
every FF feature has to be 'parity-chrome'?

It's even more interesting that Chrome also sat on this for ~5 years [3] and
are just now about to release it also.

Like the Firefox thread insinuates, will pundits credit TIDAL for lighting the
fire under browser vendors to support lossless streaming? No such link appears
to exist, aside from TIDAL already streaming to Chrome using NaCl [4], but
when we look back in 10 years and see both of the major browser vendors adding
FLAC support _now_ as opposed to any other time in the previous 5 years, what
will people think?

[1]
[https://bugzilla.mozilla.org/show_bug.cgi?id=514365](https://bugzilla.mozilla.org/show_bug.cgi?id=514365)
[2]
[https://bugzilla.mozilla.org/show_bug.cgi?id=586568](https://bugzilla.mozilla.org/show_bug.cgi?id=586568)
[3]
[https://bugs.chromium.org/p/chromium/issues/detail?id=93887](https://bugs.chromium.org/p/chromium/issues/detail?id=93887)
[4] [https://support.tidal.com/hc/en-
us/articles/202654692-HiFi-O...](https://support.tidal.com/hc/en-
us/articles/202654692-HiFi-Option-is-Greyed-Out-Not-Selectable-)

~~~
sjwright
> I wonder why this took so long.

Because supporting lossless audio streaming is as useful as supporting TIFF
images or UTF-32 text encoding. Nice to add to the spec sheet; mostly useless
in a practical setting.

The only purpose that comes to mind for delivering lossless audio within a web
page is to build, somewhat ironically, a lossy codec comparison tool which
would in turn demonstrate why lossless audio isn't necessary.

~~~
AndrewUnmuted
> lossless audio isn't necessary

As an audio engineer, I must point out what is wrong with this statement.

Sure, the average listener cannot discern between FLAC and a well-encoded
lossy audio file. However, with the Web Audio API making big advancements, the
need for in-browser FLAC support is becoming quite apparent.

People are building all sorts of web apps for creating, manipulating, and
processing audio. For this use case, working with lossy audio is out of the
question. Supporting FLAC means the ability to follow signal flow best
practices [0] without requiring the user to work with much larger PCM files.

[0]
[https://en.wikipedia.org/wiki/Audio_signal_flow](https://en.wikipedia.org/wiki/Audio_signal_flow)

~~~
mmastrac
I think this is the most reasonable argument for supporting FLAC natively. We
have support for lossless images in the browser already - TIFF isn't the image
analogue, but rather PNG.

~~~
ansgri
Except that PNG is by far not sufficient in professional image manipulation:
it's compression scheme is good and 8uc{3,4} is lossless, but beyond 8bpc
you're out of luck.

I'd love to have a wide-supported float32 format with reasonable lossless (and
maybe lossy) compression options.

Conversely, FLAC supports different resolutions and sampling rates, so it does
do the job for the sound processing.

------
mdf
Fifteen years after the initial release of FLAC – have there been any
significant developments in the lossless compression of audio since then?

I know there’s FLIF[1] for lossless image compression and Zstandard[2] for
general purpose lossless compression that have recently hit the Hacker News
front page. Are their adopted techniques not suitable for audio?

[1] [http://flif.info/](http://flif.info/)

[2] [https://code.facebook.com/posts/1658392934479273/smaller-
and...](https://code.facebook.com/posts/1658392934479273/smaller-and-faster-
data-compression-with-zstandard/)

~~~
niftich
Let's see:

\- Wavpack [1], which is a rough contemporary but offers three tiers of
presets (normal scale, high scale, extra high scale) and an innovative (and
optional) lossy/hybrid mode

\- TAK [2] which compressed better _and_ decoded faster than either, but was
initially closed-source until the dev was persuaded to open it up

\- LossyWAV [3] which isn't lossless but chops off least-significant-bits
while using noise shaping to pre-process audio and make it compress better
when fed to a lossless compressor

Most of these developments were first publicized on Hydrogenaudio. But as for
innovations in the last two years, not that I'm aware.

[1]
[http://wiki.hydrogenaud.io/index.php?title=WavPack](http://wiki.hydrogenaud.io/index.php?title=WavPack)
[2]
[http://wiki.hydrogenaud.io/index.php?title=TAK](http://wiki.hydrogenaud.io/index.php?title=TAK)
[3]
[http://wiki.hydrogenaud.io/index.php?title=LossyWAV](http://wiki.hydrogenaud.io/index.php?title=LossyWAV)

EDIT (for some more background): generally in lossless audio compression you
want to use linear prediction to predict an approximate signal for the next
few samples, then encode the difference between your predicted guess and the
actual signal in some entropy coder, like Golomb-Rice codes or Huffman or
Arithmetic coding. Although most of Zstandard's improvements are algorithmic
or implementation-related and not related to data theory, the part that could
show promise is the tANS entropy coder [4] used in Zstandard; but Golomb-Rice
codes perform well for data that comes from linear predictors; so I'm not sure
what to expect [5].

[4]
[https://github.com/Cyan4973/FiniteStateEntropy](https://github.com/Cyan4973/FiniteStateEntropy)

[5] 'Benchmarks' section under [4]

~~~
eln1
Golomb-Rice with base M is prefix code optimal for approximately geometric
probability distribution Pr(x) ~ sqrt(2)^(-Mx). Arithmetic coding or FSE/tANS
would allow to use the actual probability distribution. The question is how
large the gain could be - how far from Shannon is Golomb-Rice for this
specific type of data? If this probability distribution varies, maybe it's
worth thinking about adaptive rANS, like in Oodle LZNA and BitKnit:
[https://fgiesen.wordpress.com/2015/12/21/rans-in-
practice/](https://fgiesen.wordpress.com/2015/12/21/rans-in-practice/) ps. Is
M fixed or adapting?

~~~
niftich
Sadly my enthusiasm for compression greatly exceeds my math knowledge.

The linked resources from the RAD Game Tools people are really interesting;
they've been pushing the state-of-the-art for many years but mostly avoid the
limelight.

I found one paper [1] that muses about switching from CABAC to Golomb-Rice in
video compression, and by doing so they reduce decoding complexity while
achieving comparable compression efficiency. So I'm not sure if it'd be worth
going the other way, and whether adaptive codes are a good fit (for LPC
residuals).

[1]
[http://iphome.hhi.de/wiegand/assets/pdfs/2011_09_ICIP_entrop...](http://iphome.hhi.de/wiegand/assets/pdfs/2011_09_ICIP_entropy_cod.pdf)

But I almost want to cook up some interactive 'build-your-own lossless codec'
testbench where you could pick your transform, pick your linear predictor, and
pick your entropy coder, and tinker until you're satisfied with the result.

------
loeg
It's a little odd to me that they're adding new codec code in C++ when they
have this little memory-safe language in their back pocket waiting to be used
for exactly stuff like this.

~~~
sp332
Rust is still very new. So far the only Rust code added to Firefox was a drop-
in replacement for some other code. They haven't written any new features in
Rust yet, and most FF devs wouldn't be fluent in it yet.

~~~
loeg
It seems to me that Rust would be perfect for a tiny, mostly irrelevant, self-
contained feature like this. :-)

If it works, you don't need most FF devs to have fluency because the code base
simply doesn't need fixing. The API surface is tiny. And the impact of it
being broken is pretty low.

------
shmerl
What is the point in this exactly? FLAC is useful for selling lossless audio,
so you'd be able to re-encode it into any other codec when needed. But to play
something on-line (which browser support implies), you can as well use lossy
codec like Opus at transparent bitrate, and save the traffic in the process.

That said, it surely doesn't hurt to have that support in the browser, I just
don't see it being very useful.

~~~
joobus
FLAC is useful for listening to high quality music which hasn't been filtered
and compressed. It sounds significantly better than lossy audio. Iscit so hard
to comprehend that as more bandwidth comes online all the time, people won't
want to compromise on sound quality the way they were forced to in the past?

~~~
sjwright
> It sounds significantly better than lossy audio.

Lossy audio _can_ be completely transparent. If you disagree, you need to
provide some objective evidence, because all objective evidence points in
favour of good lossy compression being indistinguishable from lossless at
sensible bitrates.

Look, I've no problem with LAME being supported, but don't make it out to be
"significant" in terms of sound quality. Try AAC at 256kbps (what iTunes Store
has used for the past decade) or better yet, Opus. Do a serious blinded test
and amaze yourself with the results.

~~~
nsns
It all depends on how sensitive you are to these things, I've done such blind
tests, and to my ears the fall in quality was significant, even painful.

~~~
stdbrouw
Blind tests comparing lossless against what codec at what bitrate? How many
runs and how often were you able to correctly identify lossless?

~~~
themihai
Why to bother with various tradeoffs if you can get the best?(i.e lossless).
You can make the same argument on video technologies(i.e HDR). The truth is
that people usually adapt so "painful" audio or video quality stops being
painful after a while.

~~~
sjwright
If it was even remotely painful, it would sail through an ABX test.

~~~
lisivka
It may sail through months long ABX test.

~~~
sjwright
Artefacts that can only be discerned after months of sustained listening?
Sounds like you're clutching at straws.

~~~
lisivka
Not an artifact, but loss of variance in music. Same patterns are activating
same neurons, so they are tired.

------
moogly
Meanwhile, the ChromeOS release of Chromium has had support for FLAC for a
long time, but it's still feature gated on mainline Chrome.

4 year old issue:
[https://bugs.chromium.org/p/chromium/issues/detail?id=93887](https://bugs.chromium.org/p/chromium/issues/detail?id=93887)

~~~
orbitingpluto
Shouldn't casting FLAC on Chrome to a Chromecast be a priority? I may be a
curmudgeon, but I have way too many CDs in storage in those 80 litre
Rubbermaid bins that I only ever see as FLAC files on the media server.

~~~
niftich
The Chromecast can receive and play FLAC since 2015 (I can't find the exact
dates on any release notes but [1][2]).

This is about adding audio/flac decoding into Chrome; meanwhile the Chrome ->
Chromecast communication is entirely proprietary (notwithstanding the APIs),
so Google controls both ends. Since so much of the Chromecast is about handing
off content [3], there's little need to implement FLAC encoding in Chrome
because the Chromecast can just be told to load the native (original) stream
itself.

[1]
[https://www.reddit.com/r/Chromecast/comments/3n1to8/chromeca...](https://www.reddit.com/r/Chromecast/comments/3n1to8/chromecast_1st_gen_now_supports_flac/)
[2]
[https://www.reddit.com/r/Chromecast/comments/3n3epm/flac_is_...](https://www.reddit.com/r/Chromecast/comments/3n3epm/flac_is_now_supported_officially/)

[3] (Annoying ad warning but good content)
[http://www.digitaltrends.com/computing/chromecast-
features/](http://www.digitaltrends.com/computing/chromecast-features/)

~~~
orbitingpluto
Thanks for bringing me up to date. (1st gen Chromecast)

------
devongovett
For other browsers, you can use flac.js:
[http://github.com/audiocogs/flac.js](http://github.com/audiocogs/flac.js).

------
adamnemecek
I never understood why flac isn't more widely supported.

~~~
dbcooper
DRM? The project discourages implementation of DRM:

[https://xiph.org/flac/developers.html](https://xiph.org/flac/developers.html)

>Anti-goals - Copy prevention, DRM, etc. There is no intention to add any copy
prevention methods. Of course, we can't stop someone from encrypting a FLAC
stream in another container (e.g. the way Apple encrypts AAC in MP4 with
FairPlay), that is the choice of the user.

~~~
thwarted
The existence of DRM in a format is usually the reason something _doesn 't_
get supported, usually due to licensing or patent issues on the DRM, if not
because of philosophical/political/social issues around supporting DRM itself.

Do you mean to suggest that Mozilla would be/should be/are subject to third-
parties who want to restrict access to only DRM-supporting formats (I honestly
don't know if they are, but it seems unlikely)? It's not like Mozilla has a
music store and needs access to publishers/distributors that will only get on
board if there's DRM. Support for more formats can only serve to help
Mozilla's users and their market penetration (even if supporting more formats
is more of a burden, development- and support-wise).

------
VertexRed
I dont't see why people would want to use FLAC. The file sizes are huge and
the audio quality difference is bearly noticeable compared to an encoding like
.aac

Or am I missing something?

~~~
NuDinNou
> The file sizes are huge

35-70 MB it's not that huge, especially if you have a gigabit Internet
connection. And if you have a good pair of headphones you can hear the
difference between flac and aac.

~~~
pimeys
Yeah. Even with a 100 megabit internet connection the size does not matter at
all. The playing starts instantly when you push the play button and it still
uses less bandwidth than a normal youtube video.

------
stesch
I've never encountered this format. It was never relevant for me. I know about
it but that's all.

Meanwhile there are other formats that seem to be more important. What about
WebP?

At work we are currently developing a kiosk system based on a big ass touch
screen in UHD running in Google Chrome. I suggested switching to WebP for the
pictures and it is saving a lot of bandwidth compared to JPEG.

~~~
niftich
Incidentally Firefox is also adding support for WebP. Posted on HN 12 days
ago:
[https://news.ycombinator.com/item?id=12338170](https://news.ycombinator.com/item?id=12338170)

Bugzilla:
[https://bugzilla.mozilla.org/show_bug.cgi?id=1294490](https://bugzilla.mozilla.org/show_bug.cgi?id=1294490)

WebP is far from state-of-the-art but outperforms JPEG because JPEG is missing
the filtering step (where adjacent pixels are being run through a delta-coder)
entirely. An alternative is JPEG squishers like Dropbox's Lepton [1] that
tries to retrofit this deficiency in a clever meet-in-the-middle way, serving
as an additional lossless compression layer while decoding into a perfectly-
normal JPEG.

[1] [https://blogs.dropbox.com/tech/2016/07/lepton-image-
compress...](https://blogs.dropbox.com/tech/2016/07/lepton-image-compression-
saving-22-losslessly-from-images-at-15mbs/)

~~~
TazeTSchnitzel
The most exciting parts of WebP, for me, are alpha transparency in lossy
images, and animation support. This means transparent photos won't need to be
in PNG, and perhaps animated GIFs could be replaced with a more efficient
format (while still working in <img> tags and retaining their infinite loop
when downloaded).

------
c3833174
But where is my ipv6 link local address support?

------
sova
awesome!

------
jacobpadilla
Web browsers prove once again that they are still the new Emacs.

