Skip to content
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

Use variables in metadata (aka make up consecutive track numbers because the podcast's own are useless) #43

Closed
brokkr opened this issue Jan 17, 2017 · 3 comments

Comments

@brokkr
Copy link
Owner

commented Jan 17, 2017

Some podcasts leave out track numbering or play fast and loose with it, occasionally inserting 'special' shows, that do not get a track number. This can be a problem for audio players.

A solution could be to allow the user to draw on variables for insertion into the metadata, specifically:

  • Consecutive track numbering: We don't care what number the episode has in the mind of the creator, we simply label the first one '001' and take it from there, incrementing one with each new episode.
  • 'Reverse date' into title or album? Or track? (if id3 fields accept So January 18th 2017 would be 20170118 ensuring that ordering by title or album will be ordered in the order they appear.
  • Other feed data -> metadata?

This raises two related question

  • whether any or all of this does not apply equally to file naming (see issue #16 )
  • whether we want to go down the put variables into users' hands route or just add a toggle switch ("yes, please overwrite this subscription's track numbers with made up stuff")

If we want it in file names, variables is the best option. If not it might be best to contain it to a few select scenarios.

@brokkr brokkr modified the milestone: 0.8 Jan 17, 2017

@brokkr brokkr added the tagging label Jan 17, 2017

@brokkr

This comment has been minimized.

Copy link
Owner Author

commented Jan 25, 2017

Consistent with the option to use regexes in filtering, the simplest and most helpful thing is to put strftime variables into the user's hands in metadata and filenaming.

This could be datetime stuff from the feed (if and only if it is universally available) or for the time of operation. Feed data makes the most sense but it is - possibly - unreliable. Check feedparser behaviour and occurence in the wild. One option is to go with feed data, fallback to current. The problem with that is if we add an old feed without date information, we get x entries with the same date which doesn't do much to distinguish or identify the entries.

In addition to this we add our own variable ($consecutive_number?) that is saved into jar and incremented once for each succesfully added entry. This is either added by the user as a TRCK override or by a separate option.

Finally, reusing the title (<title>my_title</title>) as a variable in metadata or renaming would allow for some easy streamlining - and some useful global setting (e.g. if filename is set to $title-%Y%m%d)

On a side note: About half my subscriptions have track numbering. No current episodes have 'aberrant' track numbers. Either the feed has track numbers or it doesn't. Old episodes of 'Judge John Hodgman' display some variation: Using '118' '117/117' and '119/' within three weeks is an impressive display of indecision.

@brokkr

This comment has been minimized.

Copy link
Owner Author

commented May 17, 2017

Or maybe just go simple on this one. Tow options: Do we use it? If so what style do we use?

<track_numbering>yes</track_numbering>
<track_numbering>no</track_numbering>
<track_numbering>only_if_missing</track_numbering>

We need only_if_missing to use as a default setting. We will have to base it off of a single file which is kinda shaky.

<track_style>consecutive</track_style>
<track_style>datetime</track_style>
<track_style>regex?</track_style>

Consecutive is simply start at 001 and go from there.
Datetime is 20170517135435 (if there's room)
regex is tricky but could be used on a case by case basis if track number is available in title or filename. Probably not worth the effort, though.

@brokkr

This comment has been minimized.

Copy link
Owner Author

commented May 31, 2017

Even more simplified: We stick with the track_numbering setting which applies consecutive numbering. This leaves the door a tiny bit open for expanding with more options (and just using the original setting as a default in cae the user doesn't make it explicit).

Numbering from '1' may seem a bit odd if we know that the feed is at episode 234 and may even say so in the filename but a) it will be universally recognised by players (especially if we zero pad it) and b) it will allow us to focus on it and do it properly. KISS.

@brokkr brokkr closed this in 7971d16 May 31, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.