Wrong YouTube video metadata fields - "Movie name" and "ARTIST". #3146
Comments
|
This is intended behavior. See https://github.com/yt-dlp/yt-dlp#modifying-metadata |
pukkandan
added
question
|
To my opinion, it's weird that this behavior is default. (if you wonder, I want to preserve original title and channel name in the metadata, because of filename limitations) |
|
So might |
|
From https://github.com/yt-dlp/yt-dlp#modifying-metadata
What OP wants here is to override So: |
|
So, final command that does what I wanted is But still, I think this should be default behavior at least for YouTube videos, because it's confusing that |
|
The youtube-dl devs at some point decided to prioritize track and artist fields instead of title and uploader in the embedded video metadata. This was probably done because this is the expected result for songs. But yt-dlp can't tell songs and videos apart (I blame youtube for putting the track info in other videos). So this cannot now be changed without significantly breaking backward compatibility. Even a small (and fully justified) change to metadata embedding (putting |
|
"Movie name" is just what MediaInfo calls it anyway. In practice it's used as a general-purpose title field. |
|
Then, to prevent other people from searching through closed issues, this solution of the problem (adding a couple of |
|
But there's no example with "meta_". |
# Set "comment" field in video metadata using description instead of webpage_url
$ yt-dlp --parse-metadata "description:(?s)(?P<meta_comment>.+)" --add-metadata |
|
Oh. So, I think you should add one more example. |
|
That is the "correct" way to copy a field. The other method won't work correctly if the field has multiple lines. Youtube video titles never have multiple lines, so it's fine for that |
|
I'll add this: diff --git a/README.md b/README.md
index a2e2b34c3..c4017140f 100644
--- a/README.md
+++ b/README.md
@@ -1637,7 +1637,11 @@ $ yt-dlp --parse-metadata "description:Artist - (?P<artist>.+)"
# Set title as "Series name S01E05"
$ yt-dlp --parse-metadata "%(series)s S%(season_number)02dE%(episode_number)02d:%(title)s"
-# Set "comment" field in video metadata using description instead of webpage_url
+# Prioritize uploader (if present) as the "artist" field in video metadata
+$ yt-dlp --parse-metadata "%(uploader|)s:%(meta_artist)s" --add-metadata
+
+# Set "comment" field in video metadata using description instead of webpage_url,
+# handling multiple lines correctly
$ yt-dlp --parse-metadata "description:(?s)(?P<meta_comment>.+)" --add-metadata
# Remove "formats" field from the infojson by setting it to an empty string |
Closes #3213, Closes #3117 Related: #3146 (comment), #3277 (comment), a825ffb#commitcomment-68538986, #2360, 5fa3c9a#r70393519, 5fa3c9a#r70393254
|
@pukkandan The compatible option "embed-metadata" should change "track" to "title"/"artist" to "uploader", like the original YouTube-DL do. |
|
The bahavior of ytdl and yt-dlp are same for these fields. Explain what you mean (in a new issue) with verbose logs backing your claims |
|
Nevermind. It's the same thing. Sorry! |
|
And how to to replace meta_album with 'nothing'? I mean, remove it. |
|
Set it to an empty string |
Worked fine, thanks! But I had a problem with the title on Tumblr: downloading this video with --parse-metadata "title:%(title)s" enabled, the title gets cut just before "OST", but when this option is disabled, this problems doesn't happen. I noticed there's a line break before "OST", so this can be the cause. Some way to sovle it? |
What do you expect this to do? (probably best to open a new "question") |
Checklist
Region
Russia
Description
If YouTube video has detected music in the description,
--embed-metadataembeds title and artist of the song instead of the video title (Movie titlefield) and channel name (ARTISTfield).Example:
yt-dlp 3YvGFsc0SYw --embed-metadata: expectedMovie nameis "I sit" and expectedARTISTis "Owlspark".Got "Sugar" and "System Of A Down" instead (detected song title and artist).
Verbose log
The text was updated successfully, but these errors were encountered: