Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: metadata tags for podcasts (Read 1360 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

metadata tags for podcasts

Hello,

I've submitted an enhancement bug and a patch that (as far as I could tell) implements the enhancement to gst-plugins-base -

https://bugzilla.gnome.org/show_bug.cgi?id=725244

Would appreciate discussion.

It introduces three new metadata tags:

PODCAST (TXXX|podcast in id3v2)
EPISODE (TXXX|episode)
RSSFEED (WXXX|rssfeed)

PODCAST - purpose is to store the name of the podcast. Currently the ALBUM tag is generally used for this. iTunes for example will over-write the TALB frame with the name of the podcast, Rhythmbox will put the name of the podcast in the album node of their xml database for the entry. Most of the time that is probably functionally fine, but in a few cases there is legitimate reason for them to be different.

The other purpose I have in mind for the PODCAST tag though is identification of the media type upon manual import into the media library.

I only subscribe to a few podcasts, but several times a month I download an episode from a podcast I am not subscribed to. The PODCAST tag would give an easy way for the media library application upon import to identify that it is a podcast and do the right thing with it.

EPISODE -

If used, usually will be a non-negative integer but SnEm format can be used (e.g. S5E12) in cases where episodes are broken up into different seasons. Tracknumber does not make that much sense for podcasts, and having the field as a string will allow an adendum to be pushed. e.g. if I make a factual error in EPISODE=117 - I can record a correction to that error and push it as EPISODE=117a without needing to re-record or edit the original.

RSSFEED - the feed the podcast is part of.

That is primarily for people like me who download episodes outside the context of the feed. Would be cool if I decide I do want to subscribe, to be able to right-click on the title in my library and choose "Subscribe to Feed"

----

I am hoping to make use of these tags in Rhythmbox. I plan to implement the PODCAST tag first, so that when importing media I downloaded, as long as it has the PODCAST tag it will be imported correctly into the podcast pane. Right now I have to edit the xml database, find it, and then change type="song" to type="podcast-post" and it would be nice if I didn't have to, if the most I had to do was add the PODCAST tag to the file after downloading.

My rhythmbox hacking will also have the contents of that tag written to a new database key, not album, so the genuine album information (if different) can be put into the album node.

Rhythmbox will also use that new database key (which will probably just be podcast) instead of album for podcasts it does subscribe to. Upon download of a media file through the rhythmbox podcast interface, the the tags will be read and the proper album entry made into the rhythmbox database for the album entry.

Once the PODCAST tag is working the way I want within rhythmbox, then I'll start working on rhythmbox support for EPISODE and RSSFEED.
Probably over 90% of my coding is in php and JavaScript so this will take me a little longer than experienced GStreamer coders might take.

It might seem like a pedantic thing, but it is something that has always bugged me, so I am trying to solve it.

The rhythmbox hacking is a lot easier with the gst-plugins-base patched because then I don't have to hunt for the tags within GST_TAG_EXTENDED_COMMENT.

Thoughts / discussion?