GNOME Bugzilla – Bug 725244
Feature Request for GST_TAG_{three new}
Last modified: 2018-11-03 11:29:04 UTC
Feature Request: Three new tags related to podcasting. First Tag: PODCAST The type should be a string. In xiph/ape comments PODCAST would be the key in the key=value pair. In id3v2 PODCAST would be the description in a TXXX frame. This tag is intended to contain the human readable name of the podcast an audio or video is part of. Currently the album field is frequently used for this. For example, iTunes will over-write the TALB frame of an MP3 with the podcast name and rhythmbox will but the podcast name in the album node of their database xml file. Most of the time this is probably okay but there are case uses where it is not: Example A: Podcast covering the local music scene may occasionally do a promotional for a local band where they podcast one of their songs. In this case, the ALBUM field should be the recording album the song is from. By keeping podcast and album separate, it is possible for audio and video files where it is appropriate for them to differ to have both. Also having a podcast tag in an audio file gives media players that organize media, such as rhythmbox, a means to identify that the media file is part of a podcast upon import into the media library so that it can be given the correct type attribute in the database (e.g. podcast-post oppose to song in the case of rhythmbox) --- Second Tag: EPISODE The type should be a string. in xiph/ape comments EPISODE would be the key. In id3v2 EPISODE would be the description in a TXXX frame. This would be used to indicate the episode number within a podcast, but does not have to be exclusive to use with podcasting. The uses I see are a non-negative integer if no season is given. If a season is given, SnEm should be used where n is the season designation and m is the episode number within the season. An EPISODE value of 0 can be used for informational media about the podcast or the season if season information is given. In cases where the media file is not actually part of the podcast production itself, such as the Example A given earlier, then an EPISODE tag should not be used. In the event that there is a factual correction to an episode, a letter can be appended after the episode number in the correction to note it is an addendum. For podcasts that use the EPISODE tag, the default sort order should be by EPISODE number rather than by post-date. I know of several cases where an audio-encoding problem in an episode was corrected resulting in a re-posting of an old episode at a later date, causing sort by post-date to fail unless the podcaster uses a fraudulent post-date in the RSS feed for the re-posting. The EPISODE=m or EPISODE=SnEm is my notion of how that tag should be used, but I am not sure its use should be restricted to that format and I don't think it matters much to the GStreamer library what the format is as long as it is a string. Let the clients worry about how to sort it. --- Third Tag: RSSFEED The type should be a string but it also should be a valid URI. In id3v2 RSSFEED would be the description in a WXXX frame. This would be used to indicate the RSS feed that the podcast is a part of. It's primary purpose to me involves cases where a media file is downloaded outside the context of the podcast that it is a part of, something I commonly do. It will make it easy for the listener to subscribe to the feed at a later point in time if they so choose. A secondary purpose, if a podcast decided to change its name (say due to a trademark infringement or just for artistic reasons) it would be possible for clients that choose to do so to update the PODCAST tag (and / or entry in their database) for all media with the RSSFEED value that matches. -=-=-=-=-=-=-=-=- I do not see these tags being used in the wild, but I have been using them myself to re-tag podcasts I manually download, and I will be using them in a podcast hosting service I am working on. I also hope to patch the Rhythmbox media player used in GNOME so that I don't have to continually manually update the .xml file Rhythmbox uses every time I manually download a podcast episode I am not subscribed to. These tags being recognized by the GStreamer backend that Rhythmbox uses will make a patch the Rhythmbox and the podcast plugin easier to write and I suspect more likely to be accepted by upstream than if I used GST_TAG_EXTENDED_COMMENT to get the information. Thank you for your consideration, Michael A. Peters (a.k.a Alice Wonder) - a huge fan of GStreamer (and Lewis Carroll).
Currently working on a patch to plugins-base as that is where I think these definitions belong (that's where MusicBrainz stuff is), assuming I am successful I'll put the patch here. Might not be successful, but I *think* I will be. I'm patching against gst-plugins-base-1.2.3 and testing in Fedora 20
Created attachment 270441 [details] [review] adds the GST_TAG definitions I propose. Seems to work using gst-discoverer - tested with ogg vorbis and mp3 My guess is where I put the definitions in the files is not the best place.
Created attachment 371660 [details] [review] tags: Add support for new EPISODE, PODCAST and RSSFEED tags
Still applies cleanly against -base. Are there other "container" formats for which those tags would apply ?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/112.