Recording Time

[ozone]

I want to be able to choose in the options menu whether I want the recording time displayed as… YEAR-MONTH-DAY (i.e., 2007-12-06) or YEAR (i.e., 2007).

If implementing this would take some time, then can you at least in the next patch standardize the current method? Currently, Jaikoz appears to do no analysis during auto correction on the recording time. So you could have 1 album with five files in YEAR-MONTH-DAY format, and six files in YEAR format. I wish it would tidy the recording time up automatically for me instead of leaving songs in the same album with a different format.

[paultaylor]

[quote=ozone]I want to be able to choose in the options menu whether I want the recording time displayed as… YEAR-MONTH-DAY (i.e., 2007-12-06) or YEAR (i.e., 2007).

If implementing this would take some time, then can you at least in the next patch standardize the current method? Currently, Jaikoz appears to do no analysis during auto correction on the recording time. So you could have 1 album with five files in YEAR-MONTH-DAY format, and six files in YEAR format. I wish it would tidy the recording time up automatically for me instead of leaving songs in the same album with a different format.[/quote]

Do you want it DISPLAYED as YEAR/ YEAR-MONTH_DAY … or STORED as YEAR/YEAR_MONTH_DAY. I ask because just changing how it is displayed in jaikoz is not going to change how it is displayed in another application such as iTunes. The recordingtime value is taken from the value in the MusicBrainz database when a match is made and the value exists.

Assuming you mean STORED could add a Local Correcter for the ‘Recording Time’ column which lets you specify the format values should be held at could be an option. However if you specify you would like to store it as a full date YYYY-MM-DD and you only have the year value what should Jaikoz do. For exaxmple if the field has a value of 1984 storing it at 1984-01-01 would be misleading as it implies more accuracy then it actually has, whereas leaving it as 1984 would mean a mixture of formats.

So waiting for comments…

[Anonymous]

Stored. Sorry to confuse you with the “displayed” language I used in my first post.

Well, my thoughts are to have an option in the recording time setting to select between storing it as XXXX or XXXX-XX-XX.

As for auto-correct analysis after choosing a setting, I would add some AI.
What exactly is “Recording Time”? It is supposed to mean the year the song was recorded, and not the year of the album release; however 99% of the people that fill out musicbrainz information set it as the year of the album release. So here is my suggested AI for autocorrect:

1. If I choose XXXX as my format, then truncate all Recording Times to YEAR.

2. Filter out all albums without an album title (if we don’t know what tracks go together in an album then we cannot perform any AI).

3. If the total number of unique YEAR values for an album are less than 3, then change the YEAR to the most prevelant value for that album. Example:

Track 01 = 2007
Track 02 = 2007
Track 03 = empty
…
Track 10 = 2007
Track 11 = 2006
Track 12 = 2006
Track 13 = 2006

09 Tracks = 2007
3 Tracks = 2006
1 Tracks = empty (empty years don’t count as a unique year)

So set all tracks which are not 2007, to 2007 because there are less than three unique years in that album.

Why even bother with all this? Well if you run into a compilation album someone could have properly set the recording times on musicbrainz so there will be a ton of different years. So this AI would prevent converting an album like that improperly and it would simple truncate the year to the proper format and leave it alone.

I would also recommend this method of (less than three unique) be applied in the same way to the GENRE of an album (again, basing an album by anything having an identical non-empty title).

---

---

What about XXXX-XX-XX ?

1. Filter out all albums without an album title.

2. We have to again determine if we are dealing an album where someone lazily entered the data and set the XXXX-XX-XX to the store release date and not each individual track recording dates.

Compare all XXXX-XX-XX. If there are more than three unique values in that format then leave everything alone and go onto the next album for analysis, otherwise we perform one more check before setting all the tracks in the album to the most prevalent date. Compare the YEAR of all the tracks in that album and if there are less than three unique values for the YEAR, then assign the most prevalent XXXX-XX-XX to all the tracks otherwise leave the tracks alone.

So yes, this could leave us with a mixture of formats, but I cannot think of a better solution.

Also there is one more thing you might want to do if you decide to implement some of this stuff. In comparing XXXX-XX-XX you might want to first ensure that the middle -XX- is less than 12 and if it isn’t, then swap the two. Someone could label a track as 2007-30-12 when in reality it should read 2007-12-30. It would be good to do this before any analysis comparing tracks.

4. If the total number of unique YEAR values for an album are less than 3, then change the YEAR to the most prevelant value for that album. Example:

[Anonymous]

Disregard the last line in my previous post:

4) If the total number of unique YEAR values for an album are less than 3, then change the YEAR to the most prevelant value for that album. Example:

I was offline editing it and forgot to delete it. And because I didn’t login, I cannnot edit my post.

Ever consider disabling the ability for anonymous posting?

[paultaylor]

As you say Recording Time is used as Release Time I think I may just change it to the Year (although still allow full dates) because this si what most users know it has.

I like this autocorrect idea, although the correction/inserted of dates on an album basis would have to be optional.

Ive now stopped anonymous postings.