DEV Community: Arham

YouTube to WAV: 44.1 vs 48 kHz, 16 vs 24-bit, and what actually matters

Arham — Fri, 30 Oct 2026 13:17:10 +0000

I run a small free tool, YTtoWAV, that turns YouTube audio into WAV files. Most of the people who use it are music producers, DJs and video editors. The same few questions keep coming in through the feedback box:

"Can you make it 44.1 kHz?"
"Is 24-bit better?"
"Why is the WAV so big if the quality is the same?"

So here is the short version of what is actually going on with YouTube audio, and how to pick the right settings for your DAW or video project.

What YouTube actually gives you

YouTube does not store your audio as WAV. It stores compressed streams, usually one of these:

Opus, around 128 to 160 kbps, at 48 kHz
AAC, around 128 kbps, at 44.1 kHz

Both are lossy. Some detail was thrown away when the video was uploaded and encoded. No converter can bring that back.

So what does converting to WAV do? It decodes that stream into plain, uncompressed PCM audio. From that point on, nothing else gets lost. You can cut it, stretch it, re-export it, and you won't stack a second round of MP3 compression on top of the first one.

That is the real reason to use WAV: not to gain quality, but to stop losing more of it.

48 kHz or 44.1 kHz?

The best choice is usually the sample rate the source already has. For most YouTube videos that is 48 kHz, so a 48 kHz WAV is a straight decode with no resampling.

Pick 44.1 kHz when:

your DAW project is set to 44.1 kHz (many music templates are)
you are burning a CD or using DJ software that expects 44.1 kHz
you want every sample in your library at the same rate

Pick 48 kHz when:

you are working on video (48 kHz is the video standard)
you just want the cleanest copy of what YouTube had

Resampling from 48 to 44.1 kHz with a good resampler is not audible on normal material. It just isn't needed unless your project asks for it.

16-bit, 24-bit or 32-bit float?

This one confuses a lot of people.

16-bit is CD quality and is more than enough to hold a decoded YouTube stream.
24-bit gives you more headroom if you plan to process the file heavily (gain changes, EQ, time-stretch) before you export again.
32-bit float can't clip inside your DAW, which is handy for stems you'll push around a lot in a mix.

None of these add detail that wasn't in the YouTube stream. They give you more room to work without adding new rounding errors. If you are just dropping a sample into FL Studio or Ableton, 16-bit is fine. If you are going to mangle it, 24-bit or 32-bit float is a safe habit.

Why is the file so big?

Uncompressed audio is simple math:

sample rate × bit depth × channels

For 48 kHz, 16-bit, stereo:

48,000 × 16 × 2 = 1,536,000 bits per second (1536 kbps)

That works out to about 11 MB per minute, so a 5-minute song is around 55 MB. A 128 kbps stream of the same song is about 5 MB. Same sound, more than ten times the size, because nothing is compressed anymore.

Quick way to check what you got

Open the file in Audacity and look at the track info on the left. It shows the sample rate and the format (16-bit, 24-bit or 32-bit float). If it says 48000 Hz and you wanted 44.1 kHz, set the project rate and export again, or grab the right version from the converter in the first place.

What I settled on in the tool

After reading a few hundred feedback messages, the quality menu in YTtoWAV ended up with these options:

Option Good for
Original (16-bit, 48 kHz) Clean copy, no resampling
16-bit, 44.1 kHz DJ software, CDs
24-bit, 44.1 kHz Music production
24-bit, 48 kHz Video editing
32-bit float, 48 kHz Heavy processing, stems

There is also MP3 (up to 320 kbps), FLAC (16 or 24-bit), M4A and OGG for people who want smaller files. If you only need part of a video, a trim option lets you pick a start and end time, so you get just the sample instead of the whole track. It's free, there is no signup, and it works with normal YouTube links, youtu.be share links, Shorts and YouTube Music links.

One last thing

Only download audio you own or have permission to use. A lot of producers use this for their own uploads, for licensed sample packs, or for reference tracks they never publish, and that is the right way to use any converter.

If you have questions about sample rates, bit depth or getting YouTube audio into a specific DAW, leave a comment and I'll answer.

What 8,000 conversions a day taught me about proxy rotation

Arham — Sun, 06 Sep 2026 19:11:58 +0000

I run a small audio conversion tool. Nothing clever — you paste a link, it pulls the audio, you download it. It handles somewhere around 8,000 jobs a day now, and about 91% of the people who start a conversion actually finish the download.

Getting there took five months and four bugs I would not have found in a test environment. This is a write-up of those four.

Stack, for context: Flask, Redis, RQ workers, yt-dlp, and a pool of rotating proxies.

The setup

Requests hit a queue. Workers pick them up, choose a proxy from a weighted pool, and stream the file to disk while the user's download is already in progress. If a proxy fails, the job retries on the next one.

That last part matters. The retry chain is what gets success rate from about 92% to about 99%. It is also where three of these four bugs were hiding.

Bug 1: two proxies that were secretly one proxy

I had two entries in the pool that looked like this:

gateway-a.provider.example:PORT_1
gateway-a.provider.example:PORT_2

Same host, different ports. Different exit IPs when I tested them individually, so I treated them as independent.

They were not. They share an upstream gateway. When one got rate-limited, the other was already in trouble — but my code kept routing traffic to it, because it was keying cooldowns and slot limits on the index in the pool array, and index 2 still looked healthy.

The fix was one line — key on the thing that actually enforces the limit:

python
def proxy_key(proxy):
# Same gateway, different port = same upstream limit.
# Keying on the pool index treats them as independent,
# so a cooldown on one never reaches the other.
return f"{proxy['host']}:{proxy['port']}"

Lesson: your identity function for a resource has to match whatever enforces the limit, not whatever is convenient in your data structure.

Bug 2: rotation running inside the request path

Rotating an exit IP on this kind of proxy means asking the upstream to cycle. That call takes 25 to 36 seconds.

I had it inside the job. So roughly once every N jobs, one unlucky user waited half a minute extra while a rotation completed.

It never showed up in the median. It sat in p95, and I spent a while blaming yt-dlp for it.

python

Rotation is maintenance, not part of serving a request.

Inside the job it blocked one unlucky user for 25-36s and

only ever showed up in p95, never the median.

threading.Thread(target=_rotate_if_due, args=(cfg,), daemon=True).start()

Lesson: if a maintenance operation is slow and periodic, it does not belong in the request path — even if it is "only sometimes."
**
Bug 3: the fallback that picked the worst option**

When every slot on a proxy was busy, my code fell back to the next one:

python
fallback = (proxy_index + 1) % len(PROXIES)

Looks harmless. It is not.

The pool still contained entries I had deliberately disabled by setting their weight to zero. Weight zero kept them out of normal selection — but modular arithmetic does not know about weights. Under load, the fallback path was routing traffic to a proxy that was failing essentially every request.

python

Weight-0 entries are disabled on purpose. Modular arithmetic

doesn't know that, so pick only from the trusted set.

fallback = next_trusted(proxy_index, TRUSTED_PROXY_INDICES)

Lesson: I had two mechanisms for "this resource is disabled" — a weight and a list — and only one of them was consulted on the error path. If you disable something, disable it everywhere.

Bug 4: retrying things that were never going to work

This one had the biggest payoff and the least cleverness.

My retry chain gave every failure three attempts across three different proxies. Reasonable for a timeout or a rate limit. Completely pointless for:

video deleted
video private
age-restricted
members-only

No proxy on earth fixes a deleted video. But I was spending three attempts and roughly eight seconds finding that out, on about 2% of all jobs.

python
PERMANENT = (
"Video unavailable", "Private video", "This video has been removed",
"age-restricted", "members-only", "Sign in to confirm",
)

def is_permanent_error(msg: str) -> bool:
# No proxy fixes a deleted video. Retrying it three times
# burns ~8s and occupies a slot on every other proxy too.
return any(p.lower() in msg.lower() for p in PERMANENT)

Two things improved at once. The user gets a clear answer in about three seconds instead of eight. And the rest of the pool stops being occupied by jobs that were always going to fail — so everyone else's p95 drops as well.

Lesson: a retry policy that does not distinguish permanent from transient failures is not a retry policy. It is a delay.

Where it ended up
Before After
Success rate ~92% 99.3%
Median ~11s 6.6s
p95 30-60s ~17s
Under 10s ~60% 89%

Not all of that is the four bugs — some of it is simply better proxies. But the p95 numbers are almost entirely bugs 2 and 4.

T*wo things I got wrong for a while*

Measuring per job instead of per attempt. I was computing proxy success rates from job outcomes. But one job can touch three proxies. A good proxy cleaning up after a bad one looked identical to a proxy that succeeded on the first try. Once I counted per attempt, one entry turned out to be sitting at 82% while I thought the pool was uniform.

Trusting one-hour windows. Success rate swings several points hour to hour. I made at least two changes based on a one-hour sample that a 24-hour sample would have told me not to make.

One last thing, if you are running yt-dlp in production: update it weekly. I have a cron job that pulls the latest build every Monday and restarts workers. Pinning felt safer right up until the first time an extractor broke mid-week and we sat down until someone noticed.

The tool this runs on is https://yttowav.net/, if you want to see what the latency actually feels like.