MP3 quality degraded

[avengerx]

Version

6.5.6

Platform

.NET 9.0 / Windows 10

Steps to reproduce

Currently when using MP3 containers, the downloaded file is a constant bitrate of, often, 128 or 160kbps. This was implemented as a fix to #666.

Details

Detailed explanation in this comment

While the fix for #666 really improves the quality of the output MP3 file, the result is a CBR file, assuming the source codec's bitrate relates to the MP3 (libmp3codec)'s one. I believe this is, likely most of the times, not true.

To achieve better quality MP3 files, ffmpeg could use variable bitrate (VBR) at "best quality", which allows it to set the bitrate to whatever is needed to minimize the loss during the conversion.

The fix itself would be super simple: simply change the passed argument in @6.5.6:YoutubeExplode.Converter/Converter.cs:103-104 from -b:a:<stream> <inferred_bitrate> to -q:a:<stream> 0, which means "best quality variable bitrate".

These flags are documented in VBR Encoding - Encode/MP3 - FFmpeg.

This way, even if a low quality audio stream is input, ffmpeg will do whatever it takes to closely match it to the output MP3's variable bitrate stream. Effectively, lower quality/bitrate input means lower bitrate output, even with "maximum quality".

I couldn't reproduce the original issue discussed in the related SuperUser page, so it really seems worth a shot.

With the fix above I am instantly getting MP3 output in higher bitrate. Some tests I did:

• Outside of YoutubeDownloader / YoutubeExploder, converted 320kbps and 128 kbps mp3s (after normalization) using -q:a 0 to different results, lower average bitrate to lower bitrate source MP3s.
• Inside YoutubeDownloader, using youtube's opus-251 (details in the linked comment above), bitrates settle in considerably higher values with the new flag, but not necessarily always 260kbps+, depending on the source video it sits around 192kbps or less. It really depends on the actual complexity of the audio stream. (complexity: not quality, necessarily!)

By what I've seen, libmp3codec handles very well the encoding, but there may be reasons people want CBR; I doubt for the today's standards many people would worry about ABR (average bitrate).

Checklist

• I have looked through existing issues to make sure that this bug has not been reported before
• I have provided a descriptive title for this issue
• I have made sure that this bug is reproducible on the latest version of the package
• I have provided all the information needed to reproduce this bug as efficiently as possible
• I have sponsored this project
• I have not read any of the above and just checked all the boxes to submit the issue

[Duc558]

I have no problems with the audio.
I download the version with the highest bitrate audio codec, then use ffmpeg to convert it to the desired format at the desired frequency and bitrate.

[Tyrrrz]

Thanks for the detailed issue @avengerx. Please submit a pull request if you want.

[avengerx]

Sure, it's already in my fork