FLAC Support in Firefox 51
bugzilla.mozilla.org
bugzilla.mozilla.org
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.
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)
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.
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.
If you're writing a cross-platform application, it's often easier to be confident in platform-agnostic parsing code that uses the platform sandboxing primitives, versus yielding parsing to the operating system, which may decode in a different execution context, and be less secure compared to the application security policy.
Browsers are right to be hesitant, here. Frankly, they should be hesitant, and sandbox the plugin, and use something like rust, and even then I expect there will be exploits sometimes.
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 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=586568 [3] https://bugs.chromium.org/p/chromium/issues/detail?id=93887 [4] https://support.tidal.com/hc/en-us/articles/202654692-HiFi-O...
That also is the reason why these decisions often happen in the same time frame for different browser vendors. If another browser vendors decides to introduce it, you can be much more sure that you won't be supporting it without anyone using it. And obviously also just to not be left behind by web developers.
Something like a codec is comparatively trivial, because as a content server you can never rely on everyone supporting the same codec, so you have to stream among multiple formats anyway. When all of these JS APIs that FF or Chrome added were later deprecated and removed, everyone had to re-code their sites. So I'm hesitant to accept 'let's be really careful about this' as a rationale here.
And two of these have been replaced by complex, over engineered stuff. WebSQL was replaced by IndexedDB which can't do a simple equivalent of SELECT ... ORDER BY ... GROUP BY... without ending in callback hell, and AppCache was replaced by ServiceWorkers.
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.
So there is at least one of us who has a serious need for flac in a browser. And the bandwidth it uses is still less than with a typical full-hd video stream.
Links? "subjectively indistinguishable" would be a bit less argumentative
More here: https://www.opus-codec.org/comparison and all over https://hydrogenaud.io
Blind testing is also easy to do yourself.
There is no price difference when buying mp3 or flac and storage + bandwidth is cheap nowadays. If I need a lossy compression, I want to have a control on the compression parameters.
I promise you that you can't ABX the two.
And as I said in another branch in this discussion, mp3 + bluetooth compression is pretty awful already.
I keep all the music I own in FLAC as well, but have written scripts to transcode to Ogg Vorbis for portability.
Weirdly, this seems to be one of those tech things where it’s impossible to actually find out whether a bluetooth devices supports more than just the mandatory codecs & it’s equally impossible to find out whether your sound path is passing the source through or not. It’s all completely opaque.
Modern bluetooth devices can also negotiate various other codecs as part of the A2DP spec: https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles#Adv... including mpeg3/mpeg4 encodings but only SBC is mandatory and it seems to be impossible to tell what codec any particular Bluetooth audio device is using on any platform: I’ve not seen anything that will tell you what it’s really sending over the air.
Wireshark can read bt_hcisnoop.log as a Symbian OS Bluetooth Log (really). From a bit of fiddling you're looking for a series of AVDTP requests with GetCapabilites (to your speakers/headset/whatever) and then SetConfiguration (from your phone/player). Filtering by btavdtp.service will get you this.
I can tell you my phone is ignoring SBC and AAC support and asking for APT-X only.
(And it should be made clear that I have no in-principle issue with anyone purchasing or storing their local music library in a lossless format. It's a valid decision, particularly if you're establishing your music library in the last 5-10 years.)
What I don't want to have is an automatic lossy compression done by systems which the artist has no influence. Depending on the sound of the original music, this might have no effect or then the compression completely ruins the dynamics and sound of the original production.
On this time and age, bandwidth is cheap and the connections are fast. Disk space is cheap and cloud storage is cheap. I don't see so many reasons to use lossy files anymore and with flac I can be sure that I have the closest possible copy of the production that left the artist's studio.
In the way they are commonly used, lossy compression codecs have zero impact on dynamics. Correctly used, lossy compression can have zero audible consequence no matter how good the equipment or how "golden" the ears.
That said, a recording studio shouldn't ever be dealing with lossy codecs, because there's simply no need to, and because there's a sliver of possibility that the inaudible lossy artefacts could compound into an audible artefact over multiple generations.
The only time a lossy codec should ever be used is by distribution networks and/or end users.
That's why the compression should be done by me or by the original producer to have it done correctly case by case. Lossless is a good compromise it being easier to apply automatically for any kind of music.
For streaming audio, the ideal setting might be different depending on the commercial priorities of the service.
For audiobooks, convenient file sizes will probably be higher priority than maximal compression transparency.
For multichannel audio, you would need to progressively increase the bitrate on a per channel basis.
Agree with all your other points, and glad to see others that grok it.
I don't want artists or producers having any say in audio encoding formats – because the audio encoding format should be transparent and therefore have zero impact on the actual artwork.
Who cares what uses it has? It's a whole new area of capability. Somebody could find a new use for it. If we limit our choices based what's currently possible, we get nowhere.
You never know how a piece of audio might be used, and once you've thrown away information you can't get it back.
In a past life I was an audio engineer, and I spent hours tirelessly testing mixes on every kind of system. You are the listener I was working for.
Your reasoning seems to be "only deluded, pedantic audiophiles want lossless, and audiophiles don't listen though matrix decoders". But that begs the question - the whole point of relating my personal experience was to show how a perfectly reasonable and commonplace listening style could benefit from lossless encoding.
I completely accept that matrix decoding is a legitimate way to listen to music. I do it myself on occasion. But even before you throw lossy compression into play, it's worth acknowledging that Pro Logic decoding of a non-Pro Logic signal is hit-and-miss at best, which can often trip up or be generally unpleasant with many types of material.
[0]: https://github.com/onli/music-streamer, but there are probably better alternatives
The discussion in the bug itself covers JS flac implementations https://bugzilla.mozilla.org/show_bug.cgi?id=1195723#c2
There doesn't seem to be any testing around security, attack surface, etc. Disappointing, and not recommending that anyone use Firefox for the foreseeable future.
That's silly. By that argument no browser should ever bother adding any new features.
Browsers should add features where only they have access.
That's not clearly bad - the range of obscure formats is long & it's easier to update an app than every client - but it is a cost.
I'm still waiting for the day when the OPUS codec is supported everywhere.
OPUS is some serious next-gen shit: https://www.opus-codec.org/
> The standard allows indexed color PNGs to have 1, 2, 4 or 8 bits per pixel; grayscale images with no alpha channel may have 1, 2, 4, 8 or 16 bits per pixel. Everything else uses a bit depth per channel of either 8 or 16.
https://en.wikipedia.org/wiki/Portable_Network_Graphics#Pixe...
> TIFF is a flexible, adaptable file format for handling images and data within a single file, by including the header tags (size, definition, image-data arrangement, applied image compression) defining the image's geometry. A TIFF file, for example, can be a container holding JPEG (lossy) and PackBits (lossless) compressed images. A TIFF file also can include a vector-based clipping path (outlines, croppings, image frames).
Likewise, not many viewers (and certainly no browsers) support everything in the PNG standard. If you expect more than a simple compressor for some pixels, you're basically SoL when it comes to browsers.
This has come to nip myself (and others) when doing screenshots for old games such as Doom, where the pixel aspect ratio is not identical to the way they were displayed. It would be nice if we could just set the flag in PNG to tell it the display aspect ratio is 4:3, but literally no browsers support that flag. Instead we have to depend on lossy scaling so the pixel aspect ratio is identical to the display one.
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.
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.
No, this is "parity-web". Web browsers usually simultaneously decide to implement or enable features. Firefox isn't copying Chrome; they're implementing the same feature at roughly the same time (presumably after discussing it first), so as not to cause further web compatibility rifts.
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?
[2] https://code.facebook.com/posts/1658392934479273/smaller-and...
- 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 [2] http://wiki.hydrogenaud.io/index.php?title=TAK [3] 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
[5] 'Benchmarks' section under [4]
I'm paraphrasing from a post from the FLAC developer himself [1], after someone released an ALAC decoder created through reverse-engineering the format, back in 2005.
[1] https://hydrogenaud.io/index.php/topic,32111.msg279843.html#...
Unfortunately, the transformations that make up 'mastering' can be pretty elaborate, and for professionally-produced music there is little incentive to let the general public see their project files -- although they are occasionally made available for remixers.
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...
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.
FLAC achieved some popularity early on because it was cheap to encode and decode, and produced acceptable compression ratios. But its mindshare shot up in 2003 when Xiph.Org announced FLAC was joining their banner of codecs as their preferred lossless offering.
Mainstream interest in FLAC resulted in WMA Lossless and ALAC; that's what people were using. But in enthusiast circles, WavPack became an alternative competitor to FLAC, because it had better compression in high (but not normal), it was also open-source (which was rare in those days), and its dev was a participant in compression enthusiast communities.
After the FLAC/Wavpack duopoly, TTA was a good effort from a Russian team but it fizzled because it had no compelling differentiator against codecs with better share. The next big news was TAK, albeit the dev was relentlessly pressured to open-source.
One thing that is lacking in audio compression is the same thing as the difference between JPEG and MPEG - using past data to predict future data and only storing the difference.
Music has lots of repeating notes and passages. Isolating them (from other notes played at the same time), and only storing the slight change of how the note was played this time, vs last time should greatly increase compression ratios.
But I have not seen any audio compression that does this.
(Note this applies equally to lossless and lossy compression.)
Actually what you've described is essentially how all of lossless audio compression really works. You pre-process the signal to make it so that the 'important' parts don't take a bunch of space to store, then you feed it to a predictor, and then encode your difference in a way that it doesn't take a bunch of space to store. You can try to tune each step to try to make your next step perform better.
Lossy compression can be made to work similar, because you can just store a less accurate difference between what you predict and the original.
They also (as far as I know) don't attempt to isolate notes or voice phonemes. I.e arithmetic coding for sound.
Speech codecs (lossy) basically operate just like you describe, see [1]
[1] https://en.wikipedia.org/wiki/Vocoder#Modern_implementations
Every natively supported file format adds to the attack surface of the browser - another piece of decoding code running outside the sandbox/vm that js decoders would be forced to.
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.
It's coming along nicely, but there are still kinks to be worked out. (E.g. Android!)
https://wiki.mozilla.org/Oxidation has details.
That said, it surely doesn't hurt to have that support in the browser, I just don't see it being very useful.
Doubtful. See https://people.xiph.org/~xiphmont/demo/neil-young.html
TL;DR: encode above transparency level when using the lossy codec, and it won't have audible difference with lossless playback. But again, that's only for playback. As soon as you'd want to re-encode anything, there is no substitute for the lossless original.
So could anyone confirm or deny such a study and the mechanism exists from a basis of actual knowledge?
Here is one read on this: http://www.skeptic.com/eskeptic/10-01-06/
> That falls into some speculation area, unless actually substantiated with serious studies.
I can't remember the term that was used, but I remember reading about audible frequencies possibly being affected by inaudible frequencies in ways that are perceptible to humans. So if you have two source files played using the same equipment with one including the inaudible frequencies then they will sound subtly different due to the interaction.
With the 'getting tired' while listening thing, I know just what you mean. Listening to music on a laptop for instance is a mentally draining experience for me. I've heard it explained like this: your brain knows what a piano sounds like and when it hears the poor imitation it is busy 'filling in the blanks'. Listening on good equipment is much more relaxing - as is listening to something that isn't 128kbps.
I don't claim to know that either of the above are true, but to me they are plausible.
I'm also a little sceptical of the 'lossless is no better than good lossy' claims that inevitably come up in these discussions. While I accept that there is likely a point that audible differences between lossy and lossless would be imperceptible, I've been hearing those claims for a long time (starting with "it's digital - it's cd quality'). When I was seriously interested in these things there most definitely was a noticeable difference. I was right about 128kbps. I'm confidant I was right about 256kbps. Maybe with 320kbps that's changed now, but I don't know as I haven't had a decent stereo for some time. I'm not about to be convinced by those blind test studies that people keep pointing to as objective and conclusive - they always make me think of that one where it was 'proved' that cheap wine is just as 'good' as expensive wine.
I'll stick to lossless when possible and compress to lossy when necessary. Can't go wrong like that!
When I buy music, I always try to buy it in lossless FLACs anyway. And then I encode it to Opus for playback. But for listening to something on-line, Opus would do just fine to begin with.
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.
My comparisons were made several years ago using LAME 320 CBR, LAME VBR, OGG, lossless (WAV) 16bit 44.1kHz and lossless (WAV) 16bit 48kHz. I believe at least most professional musicians and sound engineers would be able to identify the difference between all of these; while they might not always be "worse", their sonic character is certainly different.
I.e. I will definitely fail ABX test, but I still feel difference. IMHO, ABX tests are wrong tests for that problem.
I can also hear differences between lossless/lossy encodings. If I tweak encoding parameters until I don't notice a difference, there is usually no real space saving afterwards - so why not go with lossess instead?
You also need to use a decent encoder - I compressed a video using Handbrake with a 256kbps AAC audio track a few months ago (faac/Windows), and noticed immediately that the audio was bad (I initially assumed the source was bad, but the FLAC track in the source sounded fine). Replaced it with a 192kbps AAC track using Quicktime/OSX and the quality was significantly better.
It's a sad fact that there are so many sub-par AAC encoders around. Best to use either Apples implementation, or either of those from Fraunhofer -- FhgAAC (free version distributed with Winamp), or the Open Source FDK-AAC that was developed for Android.
For those of us that care and have software that plays it, it's great but AAC is still the next best thing for compatibility on a wide range of devices (whilst still beating MP3 for sound quality and file size) which makes ad-hoc sharing with non-techies possible.
Hopefully that will continue to improve as it grows in popularity.
The blind tests may be confusing if you switch between the formats repeatedly in a short period of time but if you listen lossless audio for a long time and then you suddenly switch to a lossy format you can definitely sense the difference.
Now I'm still listening lossy audio because for some reasons I decided to cancel the Tidal subscription. I can't say the difference is really like between SD and HD video so you don't miss much but if you get used with lossless audio chances are that you can sense the difference when you switch to a lossy version.
Bandcamp is one of the few stores that does sell FLAC, maybe they'll be the one going that direction.
I can see myself building a streaming service for myself to listen to my collection while I'm on the move.
Why so? My collection is also in FLAC, but I always encode it in Opus for actual playback. Hard drive space is cheap, but FLAC will bloat your mobile storage. So the same rule applies. For playback Opus works perfectly. For encoding - FLAC is required.
Sure, if that works for you, but my collection is too big to fit on my mobile device (even after encoding it in Opus instead of FLAC).
I suppose my use case is rather rare, but even then, why not give the ability?
4 year old issue: https://bugs.chromium.org/p/chromium/issues/detail?id=93887
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... [2] https://www.reddit.com/r/Chromecast/comments/3n3epm/flac_is_...
[3] (Annoying ad warning but good content) http://www.digitaltrends.com/computing/chromecast-features/
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.
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).
6ft away (and screen size) being key. From up close, everyone can and the difference is obvious. Whereas with lossy audio, a well encoded track will sound transparent to ~99% of people, no matter how they listen or what equipment they use.
Digital audio is pretty much a solved problem in terms of transparent encoding. Consumer digital video still has a long way to go.
(That said, I do support the use of FLAC, just for that extra safety and because it doesn't really cost too much.)
Or am I missing something?
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.
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.
Bugzilla: 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...