[Bug 725244] New: Feature Request for GST_TAG_{three new}

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=725244
  GStreamer | gstreamer (core) | unspecified

           Summary: Feature Request for GST_TAG_{three new}
    Classification: Platform
           Product: GStreamer
           Version: unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: alicewonder at shastaherps.org
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


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).

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.