Improve MP3 conversion quality

[avengerx]

This closes #926 by using -q:a:<stream> 0 instead of -b:a:<stream> <input_stream_bitrate>

Notice a "drawback" of this approach is, output mp3 files will have considerably higher size. For the "not-audiophile" people and large libraries, this might mean a considerable impact.

The expected average increase is of 2/3rs (66%), but it depends both on the input quality and input codec. Opus in particular should always mean bigger files as it usually packs better quality in smaller bitrates in comparison to lame/mp3.

Ideally YoutubeExplode should accept quality control on the MP3 output, but that's really falling into a "new feature" category and is probably not the focus anymore. Having the best quality possible leaves room for manually reducing the quality after the download if size matters over quality.

p.s.: it was not my decision to join the lines, Visual Studio done it on its own will. Shall we bend to IA's will this time? :)

[avengerx]

Perhaps it's worth noting I didn't investigate whether audioStreamInfo.Bitrate.KiloBitsPerSecond is used elsewhere. It seems it's still useful, at least, to implementations using YoutubeExplode, right? So perhaps no further refactoring is necessary.

[Tyrrrz]

Are you asking on the account of whether this property should be kept or removed? In that case, yes, it should be kept since it's part of YoutubeExplode's public API.

[Duc558]

file Hdo56B1YxT4.opus
Size 5.60 Mb
Bitrate; 143,17Kbps
Frequency: 48000 Hz

ffmpeg -y -threads 3 -i "Hdo56B1YxT4.opus" -vn -ar 48000 -b:a 128k "Hdo56B1YxT4.mp3"
result:
Size: 5.36 Mb
Bitrate: 128 Kbps
Frequency 48000 Hz

ffmpeg -y -threads 3 -i "Hdo56B1YxT4.opus" -vn -ar 48000 -q:a 128k "Hdo56B1YxT4.mp3"
result:
Size: 2.75 Mb
Bitrate: 65 Kbps
Frequency 48000 Hz

Of which, -b:a is closer to opus than -q:a for the same processing. Of course, with -b:a the size is larger but the quality is better.

[avengerx]

-q:a 128k probably is interpreted as -q:a 9, which is least quality (fastest). You don't specify a bitrate to -q, it is based in variable bitrate and is related to "quality", accepting values 0 thru 9, being 0 best quality and 9 worst.
Ref: https://trac.ffmpeg.org/wiki/Encode/MP3#VBREncoding

[Copilot]

Pull Request Overview

This PR fixes MP3 audio degradation issues (issue #926) by changing the FFmpeg encoding approach from bitrate-matching to quality-based encoding. The change prioritizes audio quality over file size, resulting in better output quality at the cost of approximately 66% larger file sizes.

Key Changes:

• Replaced FFmpeg's -b:a (bitrate) parameter with -q:a 0 (quality) parameter for MP3 encoding
• Consolidated multi-line argument building into a single line

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Tyrrrz]

Thanks 🙏🏻

[Tyrrrz]

@avengerx I thought about it after merging, but do you think we could just do -q:a 0 once, instead of enumerating all streams with -q:a:[i] 0? If yes, I'll make the necessary changes.

[avengerx]

@avengerx I thought about it after merging, but do you think we could just do -q:a 0 once, instead of enumerating all streams with -q:a:[i] 0? If yes, I'll make the necessary changes.

I wouldn't mind either way. Perhaps doing it in one shot would be better readability-wise, but I'd say it's more a matter of taste than anything. I can't tell a strong disadvantage either way. Well aside of your spent energy hitting the keyboard keys to make the new commit and pull request. :)
Edit: oops, I get what you mean. I really didn't dig down to see if the second parameter to -q:a:stream actually works. It made sense that it was used to select a stream from the video, but in my tests I just used "music videos" which aren't multilanguage or anything. It would need more insight about the input and output to tell if that works. And more problems will show up: are there various audio streams (multi-language vid) does YoutubeExplode output one mp3 per audio stream? If it's a run of ffmpeg per audio stream, there may be little benefit from specifying the stream as it is now. If ffmpeg does the coherent output by itself, then maybe, yes...

Well, in short, I don't know! :P It might just work and save that loop!