Skip to content

Audio: Prioritize "original" audio tracks when selecting default #5205

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

D-Hunt3r
Copy link

Check for "original" in audio track's display name when determining which track should be the default. If any track has "original" in its name, only such tracks will be marked as default. Otherwise, fall back to existing logic.

Check for "original" in audio track's display name when determining
which track should be the default. If any track has "original" in its
name, only such tracks will be marked as default. Otherwise, fall back to existing logic.
@D-Hunt3r D-Hunt3r requested a review from a team as a code owner March 12, 2025 16:57
@D-Hunt3r D-Hunt3r requested review from syeopite and removed request for a team March 12, 2025 16:57
add missing displayname
@syeopite
Copy link
Member

This approach only works if the YouTuber hasn't set any custom labels for the audio tracks. I'm also not sure if YouTube even adds the original tag if a video has multiple audio tracks of the same language.

@absidue
Copy link
Contributor

absidue commented Mar 15, 2025

If you look at the xtags (either the property with the protobuf or the url query parameter) you can get the audio content type without having to rely on parsing display labels.

Here's how it is done in YouTube.js (removed code is the URL query parameter handling and the added code is the protobuf handling): https://github.com/LuanRT/YouTube.js/pull/909/files

@D-Hunt3r
Copy link
Author

It may not be a complete solution, but I think 80% is definitely more useful than nothing! Plus, I’ve included a fallback to the old logic.

My code has been running smoothly for a few days, and I believe it enhances the current setup.
I’m looking forward to your feedback

@absidue
Copy link
Contributor

absidue commented Mar 22, 2025

As the maintainers have already expressed concerns about the implementation in this pull request and changing to the proper approach is not that difficult (you don't even have to think of another approach as I've already provided you with a link), it probably makes more sense to do it correctly from the start, than merging an incomplete solution and then having to do a second pull request afterwards to clean it up.

@syeopite syeopite added the unfinished More work is needed on this PR, or on something this PR uses. label May 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
unfinished More work is needed on this PR, or on something this PR uses.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants