Many bands (like GD and Phish) specifically note in their rider that venues must allow and provide space for tapers to bring their rigs in.

A sibling comment in this thread pointed out my project Relisten[0], which now has over 4,000 bands who have given explicit permission for people to tape, record, and share their concerts non-commercially. We've been operating our FOSS platform for 12 years, and most of the audio is hosted by Archive.org. I can't tell you how many bands have begged us to add them to our platform.

[0] https://relisten.net (https://github.com/RelistenNet)

(The 4,000 number will be coming to web soon - it's available today on our mobile apps)

We landed an update on mobile last week that brought all 4,000 artists with a "collection" onto Relisten. That'll be coming to the web and sonos shortly as well.

We've been discussing the Aadam Jacob's collection with the archivists for some time. It comes with its own unique UX[0] and data constraints so we've been iterating on that and waiting for a critical mass of uploads before tackling it. We're getting closer though.

I agree with most of the sentiment in these comments. Archive and share non-comercially all the things!

[0] it's not "one" artist so it requires some custom UI, it should be unified through a single Aadam Jacob's collection, and it has a unique data path/structure on Archive.org relative to other collections

could just be a coincidence

Comments URL: https://news.ycombinator.com/item?id=47392479

Points: 10

# Comments: 3

The problem with exclusively using the web audio API is that the entire track must be loaded into memory before playing it, whereas HTML5 loads progressively. So we use both to balance the techniques.

In prior versions of the library, we'd load the track in parallel to HTML5 and make the switch mid-track so it's actually far less noticeable even if it does blip. I'm considering adding that to the new version.

Another alternative is building a custom buffer using RANGE requests to exclusively drive it via the web audio API. But obviously that is a far more complex undertaking (and requires the server to support RANGE requests). I'm open to implementing it, though.

Gapless 5 has a built in UI and style. Our library is headless: you bring your own UI and controls. It just depends on what your use-case is.

I just released v4 of my gapless playback library that I first built in 2017 for https://relisten.net. We stream concert recordings, where gapless playback is paramount.

It's built from scratch, backed by a rigid state machine (the sole dependency is xstate) and is already running in production over at Relisten.

The way it works is by preloading future tracks as raw buffers and scheduling them via the web audio API. It seamlessly transitions between HTML5 and web audio. We've used this technique for the last 9 years and it works fairly well. Occasionally it will blip slightly from HTML5->web audio, but there's not much to be done to avoid that (just when to do it - lotta nuance here). Once you get on web audio, everything should be clean.

Unfortunately web audio support still lacks on mobile, in which case you can just disable web audio and it'll fallback to full HTML5 playback (sans gapless). But if you drive a largely desktop experience, this is fine. On mobile, most people use our native app.

You can view a demo of the project at https://gapless.saewitz.com - just click on "Scarlet Begonias", seek halfway in the track (as it won't preload until >15s) and wait for "decoding" on "Fire on the Mountain" to switch to "ready". Then tap "skip to -2s and hear the buttery smooth segue.

Comments URL: https://news.ycombinator.com/item?id=47222271

Points: 35

# Comments: 11

Comments URL: https://news.ycombinator.com/item?id=47151545

Points: 6

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=47150417

Points: 7

# Comments: 0

Speaking more about the framework itself, the only real conclusion I have here is that I feel server components are a misunderstood and under-utilized pattern and anyone attempting to simplify their DX is a win in my book.

Next is very complex, largely because it has incrementally grown and kept somewhat backwards compatible. A framework that starts from the current API surface and grows can be more malleable and make some tough decisions here at the outset.

Crazy to see it's already being run on a .gov domain[0]. TTFGOV as a new adoption metric?

[0] https://www.cio.gov/

Comments URL: https://news.ycombinator.com/item?id=47069724

Points: 99

# Comments: 10

Had to give the Dead a little nod here

Seems like maybe there are some universal half-width characters that can be used.

https://www.unicode.org/reports/tr11/

Comments URL: https://news.ycombinator.com/item?id=47049560

Points: 2

# Comments: 0

    $ echo 'flowchart LR
        web([Frontend])
        subgraph platform [Cloud Platform]
          api([API Server])
          db[(Database)]
          api --> db
        end
        web -->|HTTPS| api' | npx box-of-rain --mermaid

                           ╔══ Cloud Platform ════════════════════╗
                           ║                                      ║
    ╭──────────╮           ║  ╭────────────╮      ╔════════════╗  ║
    │          │           ║  │            │      ║            ║  ║
    │ Frontend │ ─── HTTPS ──▶│ API Server │ ────▶║  Database  ║  ║
    │          │           ║  │            │      ║            ║  ║
    ╰──────────╯           ║  ╰────────────╯      ╚════════════╝  ║
                           ╚══════════════════════════════════════╝

You can make more precise decisions when you have complete control over the environment. When you don't, you have to make trade-offs. In this case, universality (electron and javascript) for higher RAM usage. It doesn't seem to have slowed Discord's adoption rate.

Even if they built their desktops apps in native code and UI, they'd have to build a JS website in parallel.

Comments URL: https://news.ycombinator.com/item?id=47018675

Points: 24

# Comments: 14