Hacker News new | past | comments | ask | show | jobs | submit | CharlesW's comments login

New compressed media formats always travel a decade-long path from either (1) obscurity → contender → universal support or (2) obscurity → contender → forgotten curiosity. AV1 is on one path, WebP is on another.

As someone who doesn't follow this stuff, which is on which path?

WebP remains fairly esoteric after 15 years, has always been a solution in search of a problem, and isn’t even universally supported in products by its owner.

AV1 was created and is backed by many companies via a non-profit industry consortium, solves real problems, and its momentum continues to grow. https://bitmovin.com/blog/av1-playback-support/


Funnily enough, JPEG2000-support was eventually removed everywhere. I assume the only reason this didn't happen with WebP as well is Google pushing and keeping it in Chrome.

Also the Google's lighthouse benchmark pushing webp recommendations, and people listening to it because of SEO concerns

True. I mentioned JPEG2000 because it had a similar fate, in particular no real reason to use it in the first place.

AV1 is on the path to universal support and WebP is on the path to obscurity.

Apple CPUs have AV1 support in hardware.

Only support for decoding and from A17 Pro and M3 onwards, I believe? Going to be a few years before that's commonly available (he says from the work M1 Pro.)

[edit: clarify that it's decoding only]


So does every modern GPU. This is nothing special.

I think you're arguing the same point—that there's plenty of support and it's arguably growing.

AV1's advantage narrows to ~5% over H.265 at very high data rates, in the same way that MP3 at 320 kbps is competitive with AAC at 320 kbps. But AV1 is never worse than H.265 from a VMAF/PSNR perspective at any bitrate, and of course H.265 is heavily patent encumbered in comparison. https://chipsandcheese.com/p/codecs-for-the-4k-era-hevc-av1-...

>AV1's advantage narrows to ~5% over H.265 at very high data rates.... But AV1 is never worse than H.265 from a VMAF/PSNR perspective at any bitrate,

There is a whole discussions that modern codec, or especially AV1 simply doesn't care about PSY image quality. And hence how most torrents are still using x265 because AV1 simply doesn't match the quality offered by other encoder/ x265. Nor does the AOM camp cares about it, since their primarily usage is YouTube.

>in the same way that MP3 at 320 kbps is competitive with AAC at 320 kbps.

It is not. And never will be. MP3 has inherent disadvantage that needs substantial higher bitrate for quite a lot of samples, even at 320kbps. We have been through this war for 10 years at Hydropgenaudio with Data to back this up, I dont know why in the past 2-3 years the topic has pop up once again.

MP3 is not better than AAC-LC in any shape or form even at 25% higher bitrate. Just use AAC-LC, or specifically Apple's Quick Time AAC-LC Encoder.


> There is a whole discussions that modern codec, or especially AV1 simply doesn't care about PSY image quality.

In early AV1 encoders, psychovisual tuning was minimal and so AV1 encodes often looked soft or "plastic-y". Today's AV1 encoders are really good at this when told to prioritize psy quality (SVT-AV1 with `--tune 3`, libaom with `--tune=psy`). I'd guess that there's still lots of headroom for improvements to AV1 encoding.

> And hence how most torrents are still using x265 because…

Today most torrents still use H.264, I assume because of its ubiquitous support and modest decode requirements. Over time, I'd expect H.265 (and then AV1) to become the dominant compressed format for video sharing. It seems like that community is pretty slow to adopt advancements — most lossy-compressed music <finger quotes>sharing</finger quotes> is still MP3, even though AAC is a far better (as you note!) and ubiquitous choice.

My point about MP3 vs. AAC was simply: As you reduce the amount of compression, the perceived quality advantages of better compressed media formats is reduced. My personal music library is AAC (not MP3), encoded from CD rips using afconvert.


>Today most torrents still use H.264

That's not what I'm seeing for anything recent. x265 seems to be the dominant codec now. There's still a lot of support for h.264, but it's fading.


svt-av1 has come a long ways recently; I tried it a few weeks ago.

It still (maddeningly !) defaults to PSNR, but you can change that. There are some sources where I find it now can significantly improve over H.265 at higher data rates, and, while my testing was limited, I couldn't find sources any where H.265 clearly won based on my mark-1 eyeball. This is in contrast to when I tried multiple av1 encoders 2-ish years ago and they, at best, matched H.265 at higher bitrates.


I don't care about VMAF or PSNR, I care about looking with my eyes. With x265 on veryslow and AV1 on preset 0/1, and the source being a UHD BD I was downscaling to 1080p, AV1 looked worse even while using a higher bitrate than x265. Current AV1 encoders have issues with small details and have issues with dark scenes. People are trying to fix them (see svt-av1-psy, being merged into SVT-AV1 itself) but the problems aren't fixed yet.

>see svt-av1-psy, being merged into SVT-AV1 itself

Part of it being merged for now.

It is unfortunate this narrative hasn't caught on. Actual quality over VMAF and PSNR. And we haven't had further quality improvement since x265.

I do get frustrated every time the topic of codec comes up on HN. But then the other day I only came to realise I did spend ~20 years on Doom9 and Hydrogenaudio I guess I accumulated more knowledge than most.


Well, did your "eyes" care more about fidelity or appeal?

https://cloudinary.com/blog/what_to_focus_on_in_image_compre...


Yup, have had the same experience.

I personally like Windsurf a bit more than Cursor, but recently I've been far more productive using Claude Code with an IDE than I was using a VSC-derived AIDE.

My sweet spot at the moment is Claude Desktop with mcp servers for editing and aider --watch for quick fixes. Claude Code uses way, way, way too many tokens on the large project i work most on.

Get one of the max plans! It pays for itself.

> Claude Code uses way, way, way too many tokens on the large project i work most on.

That's a very fair critique, and it makes the pay-as-you-go pricing model (vs. one of their subscription options) a completely unrealistic option for doing anything serious with Claude Code.


You don't get paid for programming?

Luckily i do, but i mean it triggers the api limit in 10 minutes amount of tokens

> * I've been far more productive using Claude Code with an IDE*

Curious why proportionately few seem to find this a better way of working.

Does it have to do with familiarity with XP or pair programming? What had you trying in IDE first, and what prompted you to try switching?

Have you used https://aider.chat to compare? If so, thoughts?


> …creating a custom format with backwards PNG compatibility and using steganography to cram metadata inside is an inefficient and over-engineered alternative to a .tar.gz with "image.png" and "metadata.json"

So, "perfect Show HN"? ¯\_(ツ)_/¯


Apple adopted the “Model Year” convention, used by autos and many other kinds of products. https://en.wikipedia.org/wiki/Model_year

Not necessarily more, but importantly the cadence is fixed at one GOP per second — a good (and not-unusual) choice for progressive download delivery.

> Unrelated to the video content, the technical delivery of the video is stunningly good.

To save readers a "View Source", this is the typical progressive file download user experience with CDNs that support byte-range requests.


https://en.wikipedia.org/wiki/MusicBrainz

”MusicBrainz was founded in response to the restrictions placed on the Compact Disc Database (CDDB), a database for software applications to look up audio CD information on the Internet. MusicBrainz has expanded its goals to reach beyond a CD metadata (information about the performers, artists, songwriters, etc.) storehouse to become a structured online database for music.”

More detail here: https://courses.cs.umbc.edu/771/papers/ieeeIntelligentSystem...


Harmony (https://harmony.pulsewidth.org.uk/) is amazing, and completely changed my relationship with MusicBrainz.

What are you using for tag reading/writing in Go? Robust, complete options are non-existent in JavaScript land (Deno, Bun, Node, etc.), so I ended up creating a Wasm version of TagLib with a TypeScript API.


haha that's funny! I made a WASM TagLib for Go

https://github.com/sentriz/go-taglib


Cooool, I love that you arrived at the same conclusion! Mine's not ready for its ShowHN, but as an enthusiast, I'm super-excited to dig into yours. Very nice work!

MusicBrainz Picard is wonderful, but has one of the most unintuitive "first contact" experiences I can remember. If you're not sure how to get started, try this:

• Drag your album folders (one at a time so it doesn't get confused) into the pane that initially shows "Unclustered Files (0)" and "Clusters (0)".

• Select the "Clusters" folder in that pane and click "Lookup". This will find any close matches, and in my experience works ~25% of the time.

• For albums that weren't auto-matched, right-click the album folder name and choose "Search for similar albums…". As long as you're sorting by "Score", often you'll find a reasonably-good match in the top 5 options.

• NEVER use "Scan", basically.

For matched albums, carefully review things like album covers, titles, etc. before you "Save" the updated metadata. After using it to rebuild my personal music library, including ~200 contributions to the MusicBrainz database, I still haven't cracked (for example) how to stop Picard from defaultly replacing a perfect, 1500px album cover with a less-good, 1000px cover from its database.


> MusicBrainz Picard is wonderful, but has one of the most unintuitive "first contact" experiences I can remember.

Seconded, it's the best specialised UI I've seen in a while.

By "specialised" I mean it's entirely bespoke to a specific task and no other, with a small amount of dedicated jargon, like those industrial control panels full of buttons, toggles, and blinkenlights.

At first it's completely alien and appears to do weird stuff, possibly counterintuitive even (the mentioned "Scan" usage†, "what are clusters?", "why do I even need to cluster first?", "how do I save changes?")

But once you get the hang of it it's incredibly efficient with a ton of small niceties, like dragging a selection of entries from the left side will apply whatever candidates you have on the right side to the selection in order starting from the first.

† I use scanning only when album matching fails for whatever reason, it does sometimes unearth entries that wouldn't appear otherwise.


I gave up and use Lidarr since it's a really easy interface ...until the metadata is missing from the API database then it's a hair pulling experience to learn the quirks of the culture that runs either of those cd databases.

For cover art you can control it from options->options->cover art. There are also a couple of plugins for other sources.

There are a few items in there to control if it scans external or overwrite. Recently went thru this as apparently for some reason I had totally disabled it. Think I was trying to speed up scanning as it would download every artwork for a large group into the temp folder. I usually force it to make an external file. I pick what it suggested 'cover'. Then use something like fileoptimizer to recompress the jpg/png it comes up with. I do that because I like to embed the images. And much of what is out on the net is optimized for fast editing not 'archive'. I use mp3tag to put it back into the tag.

Scan is hit or miss. I have fed it whole albums and it will somehow find 3 other albums with some of the songs from that one. That could be because of how I have options->options->metadata->Prefered Releases set. That slider bar thing for some reason I can not wrap my head around. It is good for when you come across one of those items where someone else tagged it as 'weird al' (everything is weird al if it is funny). I have been slowly getting rid of that stuff but want to find the original album to buy. Musicbrainz can be good for that sort of thing. I have also had decent luck with it if I pre-add the albums then scan. It seems to find things better.


I just went through an exercise fixing up tags on my music collection and it surprised me how bad the landscape is (and still better than book tagging, video tagging, etc).

MusicBrainz has an amazing database, but a huge amount of stuff from bandcamp/beatport isn't there. Why wouldn't you automatically import that?

So I ended up using OneTagger which I really wouldn't recommend to anyone, but was still marginally better than tagging by hand after I learned the footguns and restored from backups several times.


> MusicBrainz has an amazing database, but a huge amount of stuff from bandcamp/beatport isn't there. Why wouldn't you automatically import that?

This is why Harmony is life-changing. Ideally, it would become an official MusicBrainz project and be integrated into the site, and into Picard.

For example, here's what happens when I search for a Brandcamp release by its Bandcamp URL: https://harmony.pulsewidth.org.uk/release?url=https%3A%2F%2F...

By clicking the "Import into MusicBrainz" button at the bottom, you can very quickly (usually ~2 minutes, once you get over the MusicBrainz learning curve) add this release as a new "release group", or as a new release in an existing group.


So that's bandcamp->musicbrainz, and then picard can get it from musicbrainz as usual? I assume you need an account. That sounds great though, I guess the point is to have someone in the loop to sanity check things?

> So that's bandcamp->musicbrainz, and then picard can get it from musicbrainz as usual?

Exactly, using Harmony for the Bandcamp→MusicBrainz bit. You just paste the MusicBrainz URL into Picard's search box (upper right-corner of window) immediately after you've submitted.

> …I guess the point is to have someone in the loop to sanity check things?

I'm honestly not sure what the rationale might be for having a human editor in the loop for sources like Bandcamp, Apple Music, Spotify, etc.


>NEVER use "Scan", basically

never use "scan" because it will never work? or because it is somehow destructive and will mess up your "cataloging"?


I have no doubt that it sometimes works, and would be happy to accept a verdict of "skill issue" if the problem is me.

Scanning a Cluster should (IMO) cause Picard to generate a series of AcoustID fingerprints/IDs from the tracks, then use that series to identify the best match (with extra points for handling missing tracks, etc.). But especially in the case of collections/compilations, the end result often resembles a transporter accident. Thankfully it's non-destructive, so it's straightforward to "Remove" all of the tracks you dragged in earlier along with the various albums that MusicBrainz created during the discombobulation process.

To be clear, my overall opinion of MusicBrainz and MusicBrainz Picard is that they are unappreciated triumphs. It would be nice if Wikipedia and Internet Archive diverted 0.01% of their fundraising to them. Google is the primary hero in their story, supporting them with over $500K so far. https://metabrainz.org/sponsors


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: