20 ms·

FLAC Support in Firefox 51

317 points by kawera 10y ago

adamnemecek 10y ago
I never understood why flac isn't more widely supported.
- dbcooper 10y ago
  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 10y ago
    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).
  - masklinn 10y ago
    Hasn't it been years since DRMs were last used for music?
- DINKDINK 10y ago
  As an advocate of FLAC, it has limited appeal beyond Hi-fi geeks / archivists / or music makers. Heck even storing local MP3 files is dated (though not recommended) with the proliferation of comprehensive streaming services (no endorsement on my part)
  - sotojuan 10y ago
    Well, you can "stream" FLAC from services like Tidal (which I'm guessing makes audiophiles barf), but they're not doing so well.
    - ZenoArrow 10y ago
      You can buy music in FLAC format from Bandcamp, which is probably the number one music site for independent musicians. https://bandcamp.com/ https://bandcamp.com/ https://en.m.wikipedia.org/wiki/Bandcamp https://en.m.wikipedia.org/wiki/Bandcamp
      - DINKDINK 10y ago
        Juno music also allows for FLAC download purchases.
- ChrisGranger 10y ago
  I think it's overkill for some use cases where lossy compression does a sufficiently good job. Most people can't consistently distinguish between high bit-rate lossy encodings and their original source material most of the time. Streaming FLAC will gobble a lot of bandwidth, and some people might find that to be a problem, especially on a capped data plan.
  - joobus 10y ago
    This answer is just being contrary to be contrary. 'Most people' can't distinguish 1080p from 4k from 6 ft away, yet people still stream 4k content, which 'gobbles bandwidth' too.
    - niftich 10y ago
      I found it a perfectly valid comment that illustrates the trade-offs that developers who have to code in support for the format would make, trade-offs that content streamers debating their codec choices would make, and trade-offs that consumers choosing their preferred format would make. Historically while streaming, lossy has been 'good enough' for reasons other than nothing else was supported.
    - dawnerd 10y ago
      Is say most people not being able to feel the difference between 1080 and 4K to be inaccurate. I'm always seeing people look at 4K video after watching 1080 content and remarking how crisper it is. Of course there is a very large majority of people where what they have is good enough. When the iPhone went retina people argued that the extra pixels won't make a difference. Then they tried it. Now look where we are.
    - whyoh 10y ago
      >'Most people' can't distinguish 1080p from 4k from 6 ft away 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.)
sova 10y ago
awesome!
niftich 10y ago
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-Option-is-Greyed-Out-Not-Selectable- https://support.tidal.com/hc/en-us/articles/202654692-HiFi-O...
- Sylos 10y ago
  Why this takes so long is because once such a standard is introduced, you can't take that decision back anymore without breaking a lot of things. They don't want to introduce standards which end up being used only by a small number of people while causing a lot of maintenance-work and then being tied to maintaining it anyways. 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.
  - niftich 10y ago
    Maybe so. The counterpoint is that several of APIs added to the web platform in the last ~8 years have already been deprecated: stuff like WebSQL, File System, AppCache; there is no shortage of moving fast and breaking things when it comes to browser vendors. 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.
moogly 10y ago
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 10y ago
  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 10y ago
    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/chromecast_1st_gen_now_supports_flac/ https://www.reddit.com/r/Chromecast/comments/3n1to8/chromeca... [2] https://www.reddit.com/r/Chromecast/comments/3n3epm/flac_is_now_supported_officially/ https://www.reddit.com/r/Chromecast/comments/3n3epm/flac_is_... [3] (Annoying ad warning but good content) http://www.digitaltrends.com/computing/chromecast-features/ http://www.digitaltrends.com/computing/chromecast-features/
    - orbitingpluto 10y ago
      Thanks for bringing me up to date. (1st gen Chromecast)
shmerl 10y ago
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 10y ago
  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?
  - shmerl 10y ago
    > FLAC is useful for listening to high quality music which hasn't been filtered and compressed. It sounds significantly better than lossy audio. Doubtful. See https://people.xiph.org/~xiphmont/demo/neil-young.html 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.
    - Noseshine 10y ago
      I can't for the live of me think of a phrase that gives me Google search results even remotely related to the topic, but I am pretty sure I once found a study that said that consciously inaudible differences in audio due to compression still made a difference - subjects who got the compressed sounds tired more quickly (of hearing them). Having taken a bit of neuroscience I can easily accept that - but I did not take enough (ns) to say for sure that it is so. I can easily accept that merely asking people about anything is not actually objective, it needs more credulity to believe my claim that even people in a blind test who can't tell the difference between two songs (lossless vs. compressed), which is more objective than just asking about qualitative measures, is not a reliable way to determine the question of "lossless vs. compressed". So could anyone confirm or deny such a study and the mechanism exists from a basis of actual knowledge?
mdf 10y ago
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-faster-data-compression-with-zstandard/ https://code.facebook.com/posts/1658392934479273/smaller-and...
- niftich 10y ago
  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]
  - cpeterso 10y ago
    There is also ALAC (Apple Lossless Audio Codec), which has been open source and royalty-free since 2011: https://en.wikipedia.org/wiki/Apple_Lossless https://en.wikipedia.org/wiki/Apple_Lossless
devongovett 10y ago
For other browsers, you can use flac.js: http://github.com/audiocogs/flac.js http://github.com/audiocogs/flac.js.
stesch 10y ago
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.
- AsyncAwait 10y ago
  FLAC is very important indeed if you care about lossless music at all. Basically, when you buy a CD and want to preserve it digitally in its original quality, you go FLAC.
- niftich 10y ago
  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-compression-saving-22-losslessly-from-images-at-15mbs/ https://blogs.dropbox.com/tech/2016/07/lepton-image-compress...
  - TazeTSchnitzel 10y ago
    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 10y ago
But where is my ipv6 link local address support?
captainmuon 10y ago
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 10y ago
  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)
  - nwah1 10y ago
    Good point. Decoders for various formats are being reimplemented in Rust, which may make Mozilla less hesitant. There's still no guarantees, but it seems much less dangerous.
    - acdha 10y ago
      It will definitely help but it also increases the cost of adding support if that means porting an existing code base and having to maintain it. It'll be interesting to see whether projects start migrating wholesale so that's not just a Mozilla effort.
loeg 10y ago
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 10y ago
  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 10y ago
    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.
- kibwen 10y ago
  I wouldn't be surprised if this has been in the works since before Rust was successfully integrated into Firefox's build system. Now that it has been, I'd expect brand-new development of this nature to start considering using Rust, but I still wouldn't expect 100% of new development to be in Rust because I don't expect FF devs to immediately become experts in a new language before getting work done. And C++ still beats Rust in IDE support, which for many devs might be their most important consideration.
  - nnethercote 10y ago
    > Rust was successfully integrated into Firefox's build system It's coming along nicely, but there are still kinks to be worked out. (E.g. Android!) https://wiki.mozilla.org/Oxidation https://wiki.mozilla.org/Oxidation has details.
jacobpadilla 10y ago
Web browsers prove once again that they are still the new Emacs.
VertexRed 10y ago
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 10y ago
  > 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 10y ago
    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.

317 points by kawera 10y ago

adamnemecek 10y ago

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

dbcooper 10y ago
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 10y ago
  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).
- masklinn 10y ago
  Hasn't it been years since DRMs were last used for music?
DINKDINK 10y ago
As an advocate of FLAC, it has limited appeal beyond Hi-fi geeks / archivists / or music makers. Heck even storing local MP3 files is dated (though not recommended) with the proliferation of comprehensive streaming services (no endorsement on my part)
- sotojuan 10y ago
  Well, you can "stream" FLAC from services like Tidal (which I'm guessing makes audiophiles barf), but they're not doing so well.
  - ZenoArrow 10y ago
    You can buy music in FLAC format from Bandcamp, which is probably the number one music site for independent musicians. https://bandcamp.com/ https://bandcamp.com/ https://en.m.wikipedia.org/wiki/Bandcamp https://en.m.wikipedia.org/wiki/Bandcamp
    - DINKDINK 10y ago
      Juno music also allows for FLAC download purchases.
ChrisGranger 10y ago
I think it's overkill for some use cases where lossy compression does a sufficiently good job. Most people can't consistently distinguish between high bit-rate lossy encodings and their original source material most of the time. Streaming FLAC will gobble a lot of bandwidth, and some people might find that to be a problem, especially on a capped data plan.
- joobus 10y ago
  This answer is just being contrary to be contrary. 'Most people' can't distinguish 1080p from 4k from 6 ft away, yet people still stream 4k content, which 'gobbles bandwidth' too.
  - niftich 10y ago
    I found it a perfectly valid comment that illustrates the trade-offs that developers who have to code in support for the format would make, trade-offs that content streamers debating their codec choices would make, and trade-offs that consumers choosing their preferred format would make. Historically while streaming, lossy has been 'good enough' for reasons other than nothing else was supported.
  - dawnerd 10y ago
    Is say most people not being able to feel the difference between 1080 and 4K to be inaccurate. I'm always seeing people look at 4K video after watching 1080 content and remarking how crisper it is. Of course there is a very large majority of people where what they have is good enough. When the iPhone went retina people argued that the extra pixels won't make a difference. Then they tried it. Now look where we are.
  - whyoh 10y ago
    >'Most people' can't distinguish 1080p from 4k from 6 ft away 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.)

sova 10y ago

awesome!

niftich 10y ago

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-Option-is-Greyed-Out-Not-Selectable- https://support.tidal.com/hc/en-us/articles/202654692-HiFi-O...

Sylos 10y ago
Why this takes so long is because once such a standard is introduced, you can't take that decision back anymore without breaking a lot of things. They don't want to introduce standards which end up being used only by a small number of people while causing a lot of maintenance-work and then being tied to maintaining it anyways. 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.
- niftich 10y ago
  Maybe so. The counterpoint is that several of APIs added to the web platform in the last ~8 years have already been deprecated: stuff like WebSQL, File System, AppCache; there is no shortage of moving fast and breaking things when it comes to browser vendors. 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.

moogly 10y ago

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 10y ago
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 10y ago
  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/chromecast_1st_gen_now_supports_flac/ https://www.reddit.com/r/Chromecast/comments/3n1to8/chromeca... [2] https://www.reddit.com/r/Chromecast/comments/3n3epm/flac_is_now_supported_officially/ https://www.reddit.com/r/Chromecast/comments/3n3epm/flac_is_... [3] (Annoying ad warning but good content) http://www.digitaltrends.com/computing/chromecast-features/ http://www.digitaltrends.com/computing/chromecast-features/
  - orbitingpluto 10y ago
    Thanks for bringing me up to date. (1st gen Chromecast)

shmerl 10y ago

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 10y ago
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?
- shmerl 10y ago
  > FLAC is useful for listening to high quality music which hasn't been filtered and compressed. It sounds significantly better than lossy audio. Doubtful. See https://people.xiph.org/~xiphmont/demo/neil-young.html 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.
  - Noseshine 10y ago
    I can't for the live of me think of a phrase that gives me Google search results even remotely related to the topic, but I am pretty sure I once found a study that said that consciously inaudible differences in audio due to compression still made a difference - subjects who got the compressed sounds tired more quickly (of hearing them). Having taken a bit of neuroscience I can easily accept that - but I did not take enough (ns) to say for sure that it is so. I can easily accept that merely asking people about anything is not actually objective, it needs more credulity to believe my claim that even people in a blind test who can't tell the difference between two songs (lossless vs. compressed), which is more objective than just asking about qualitative measures, is not a reliable way to determine the question of "lossless vs. compressed". So could anyone confirm or deny such a study and the mechanism exists from a basis of actual knowledge?

mdf 10y ago

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-faster-data-compression-with-zstandard/ https://code.facebook.com/posts/1658392934479273/smaller-and...

niftich 10y ago
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]
- cpeterso 10y ago
  There is also ALAC (Apple Lossless Audio Codec), which has been open source and royalty-free since 2011: https://en.wikipedia.org/wiki/Apple_Lossless https://en.wikipedia.org/wiki/Apple_Lossless

devongovett 10y ago

For other browsers, you can use flac.js: http://github.com/audiocogs/flac.js http://github.com/audiocogs/flac.js.

stesch 10y ago

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.

AsyncAwait 10y ago
FLAC is very important indeed if you care about lossless music at all. Basically, when you buy a CD and want to preserve it digitally in its original quality, you go FLAC.
niftich 10y ago
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-compression-saving-22-losslessly-from-images-at-15mbs/ https://blogs.dropbox.com/tech/2016/07/lepton-image-compress...
- TazeTSchnitzel 10y ago
  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 10y ago

But where is my ipv6 link local address support?

captainmuon 10y ago

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 10y ago
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)
- nwah1 10y ago
  Good point. Decoders for various formats are being reimplemented in Rust, which may make Mozilla less hesitant. There's still no guarantees, but it seems much less dangerous.
  - acdha 10y ago
    It will definitely help but it also increases the cost of adding support if that means porting an existing code base and having to maintain it. It'll be interesting to see whether projects start migrating wholesale so that's not just a Mozilla effort.

loeg 10y ago

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 10y ago
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 10y ago
  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.
kibwen 10y ago
I wouldn't be surprised if this has been in the works since before Rust was successfully integrated into Firefox's build system. Now that it has been, I'd expect brand-new development of this nature to start considering using Rust, but I still wouldn't expect 100% of new development to be in Rust because I don't expect FF devs to immediately become experts in a new language before getting work done. And C++ still beats Rust in IDE support, which for many devs might be their most important consideration.
- nnethercote 10y ago
  > Rust was successfully integrated into Firefox's build system It's coming along nicely, but there are still kinks to be worked out. (E.g. Android!) https://wiki.mozilla.org/Oxidation https://wiki.mozilla.org/Oxidation has details.

jacobpadilla 10y ago

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

VertexRed 10y ago

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 10y ago
> 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 10y ago
  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.