Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Understanding the default value of -S in the context of audio #3818

Closed
4 tasks done
emphoeller opened this issue May 20, 2022 · 9 comments
Closed
4 tasks done

Understanding the default value of -S in the context of audio #3818

emphoeller opened this issue May 20, 2022 · 9 comments
Labels
question Question

Comments

@emphoeller
Copy link

Checklist

Question

I have read some issues about having yt-dlp automatically select the “best” video format (#458, #1232, #2432, #2469), but I couldn’t find similar information on audio formats. In the default value of -S, lang,quality,res,fps,hdr:12,codec:vp9.2,size,br,asr,proto,ext,hasaud,source,id, the first entry that is relevant for audio-only formats (ignoring lang and quality) seems to be codec:vp9.2, which I’m guessing is equivalent to vcodec:vp9.2,acodec (the documentation does not touch on this special case). So the audio codec is more important than the bitrate (br) or the audio sampling rate (asr), which I thought to be the most important metrics for audio files. But even the file size is considered before them.

I understand that better codecs can compress equal-quality audio better and thus yield lower bitrates and file sizes (at least I have read such for videos). Still, for videos, the resolution is listed before the codec; and the same goes for the framerate (the equivalent of the sampling rate). Additionally, the audio files of the highest quality might not even be offered in the codec that yt-dlp considers best.

So then what am I missing? Why is the default value the way it is?

Verbose log

No response

@emphoeller emphoeller added the question Question label May 20, 2022
@pukkandan
Copy link
Member

which I’m guessing is equivalent to vcodec:vp9.2,acodec

Correct

So the audio codec is more important than the bitrate (br) or the audio sampling rate (asr),

Yes

But even the file size is considered before them.

You mean "after"?

Still, for videos, the resolution is listed before the codec;

There is obv no equivalent of resolution for audio. If we know some audio is better than others we instead set the quality accordingly (eg: youtube)

and the same goes for the framerate (the equivalent of the sampling rate).

While they are similar in a technical sense, I believe the samplerate is not nearly as important as framerate as a measure of quality. If you think otherwise, we can discuss (not that I remember ever seeing a service offer audio in different sample rates)

Additionally, the audio files of the highest quality might not even be offered in the codec that yt-dlp considers best.

How does that matter?

@emphoeller
Copy link
Author

But even the file size is considered before them [bitrate and audio sampling rate].

You mean "after"?

Does size,br,asr not mean “size before bitrate before audio sampling rate”?

Additionally, the audio files of the highest quality might not even be offered in the codec that yt-dlp considers best.

How does that matter?

What I’m saying is that yt-dlp might neglect the best audio files because the platform uses a codec for them that yt-dlp considers worse.

If we know some audio is better than others we instead set the quality accordingly (eg: youtube)

However, formats with worse audio can be assigned a higher quality if they have good video. Because of this, for YouTube, the file with the best audio is still downloaded only because yt-dlp always tries to download the best audio-only file – and on YouTube, the best audio is in audio-only files. I can see this fall apart in cases where the best audio is in a file with sub-optimal video. (For those cases, it might be necessary to split quality into video_quality and audio_quality and specify separate sorting priorities for bestvideo and bestaudio.) Is this only not accounted for because there are no known sites to do this?

(Also, what’s up with yt-dlp reporting audio bitrates of 0 for certain formats with audio, e.g. format 22 of ZBgJJPZjg2k? Should I open an issue for that?)

@pukkandan
Copy link
Member

I was talking about comparing audio against audio. Merged formats cannot be reliably compared against audio-only formats. See #979 (comment)

But even the file size is considered before them [bitrate and audio sampling rate].

You mean "after"?

Does size,br,asr not mean “size before bitrate before audio sampling rate”?

You are right, I misunderstood. As I mentioned, I haven't actually seen any website that serves audio in multiple asr, but ig it makes sense to move it's priority atleast above size

@emphoeller
Copy link
Author

Merged formats cannot be reliably compared against audio-only formats.

Too bad I guess. Thanks for all the answers!

@chrizilla
Copy link

Still, for videos, the resolution is listed before the codec;

There is obv no equivalent of resolution for audio.

The nearest equivalent to video resolution is audio sample rate.

and the same goes for the framerate (the equivalent of the sampling rate).

Video framerate and audio sampling rate are not equivalents but false friends.

While they are similar in a technical sense,

They are similar only in a linguistic sense, not in a technical sense. The video framerate affects the smoothness of the video motion, i.e. the visual trick of perceiving motion in a series of still images. Since video is composed of images and audio is not composed of any equivalent of still images, it is obvious that there is no and cannot be an audio equivalent for the video framerate.

As said above, the video resolution could be considered the nearest comparison.

I believe the samplerate is not nearly as important as framerate as a measure of quality. If you think otherwise, we can discuss

It's the other way round. The video framerate affects the quality of the appearance of the video motion, but it's not trivial to say how the framerate affects the quality of a video still image. This depends heavily on the codec, the settings, the source material, etc. On the other hand the audio sample rate heavily affects the audio quality. Have you ever listened to music with a low sample rate ?

@pukkandan
Copy link
Member

pukkandan commented Apr 7, 2023

Do you have any real example where sorting by asr would be better than the current defaults? If not, further discussion seem pointless tbh.

@chrizilla
Copy link

chrizilla commented Apr 7, 2023

Do you have any real example where sorting by asr would be better than the current defaults? If not, further discussion seem pointless tbh.

I was not advocating for a specific change in the sort order. I just wanted to help, because some basics got mixed up.

I find it difficult to say whether asr or size/br (they are related) is more important, since a low value for either one degrades quality. It's like for a JPG file: low resolution or small file size both degrade the image quality. It's a bit like comparing apples to oranges or asking if the lung or the heart is more important to the human body ...

@pukkandan
Copy link
Member

I find it difficult to say whether asr or size/br (they are related) is more important, since a low value for either one degrades quality. It's like for a JPG file: low resolution or small file size both degrade the image quality. It's a bit like comparing apples to oranges or asking if the lung or the heart is more important to the human body ...

Such is the difficulty of setting a default sort order. Hence why I always ask for practical examples. Our objective is to get a default that works in most cases, and don't really care much about the technical details.

@chrizilla
Copy link

Ok then let's just leave it at that, as your thoughts on video quality equally apply to audio quality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Question
Projects
None yet
Development

No branches or pull requests

3 participants