1 (edited by xteejx 2012-07-22 14:26:38)

Topic: Earliest Recording Date help

Hi guys,

I'm using Picard to help tag music at a local radio station, but the earliest recording date is needed in the %date% field.
I am using the Last FM + plugin for Genre tagging and the Original Release Date plugin by Philipp Wolfer to try and grab the
earliest release date. Picard doesn't seem to do the last on its own.
I'm using $set(date,%originaldate%) to set date as the found one from the Original Release Date plugin, and it seems to work.
The problem is, a lot of remastered tracks have different audio fingerprints, and Picard doesn't seem to put the earliest /recorded/
date in, which is what I need it do to. i.e. The Beatles have a track remastered in 2000, but it's recorded in 1960-something.

Is there any way to use a plugin or tagger script of some kind to grab this data, or does it completely rely on relationships to work?
I'm not sure the Original Release Date script goes through the relationships or search for the track and artist to /find/ this info.


Any help with this would be EXTREMELY appreciated!! :)


Here is the complete settings that we're using:

Picard Settings:

General

Automatically scan new files X
Ignore MBIDs when loading new files X


Metadata

All X

Preferred release All Default (Reset All)

Folksonomy Tags
Ignore seen live,favourites,fixme,owned
Only use my tags --
Minimal tag usage 90%
Maximum number of tags 5
Join multiple tags with (BLANK)

Ratings - Disabled

Tags

Write X
Preserve --
Clear X
Remove ID3 X
Remove APEv2 X
ID3v2 version 2.3
Also X
ID3 enc. UTF-16

Cover Art
Location
Embed X
Save --

File Naming
REname X
Replace X
Move X M:\Jazler Music DB
Delete X
Move --

Name files like this
$left(%originaldate%,4)/$if($and($eq(%compilation%,1), $eq(%albumartist%,Various Artists)), $unset(albumartist) $unset(albumartistsort))/%artist% - %title%

Fingerprinting
Audio X
Use Acoust ID X
Use AMpliFIND --
Api Key Bms7BT2W

Plugins
Feat X
Last.fm.plus X
Orginial Release Date X

Last FM Plus
Major 0
Minor 0
Max mood 0
Max occasion 0
Max category -
Prepend --
Join tags with ;
Enable - NONE --
Tack Based
Use X
Min weight 5
Max 90
Artist -- Extend
Artist 95
Min 10
Max 80

Tag filter lists >> Load Defaults

Matching thresholds all 95%

Scipting
Tagger Script:
$set(date,%originaldate%)

Re: Earliest Recording Date help

xteejx wrote:

Hi guys,

I'm using Picard to help tag music at a local radio station, but the earliest recording date is needed in the %date% field.
I am using the Last FM + plugin for Genre tagging and the Original Release Date plugin by Philipp Wolfer to try and grab the
earliest release date. Picard doesn't seem to do the last on its own.

Which Picard version are you using? Picard has supported originaldate without a plugin for several versions now (since 0.15.1 I think), and you really shouldn't be using that original date plugin anymore as the methodology it uses is outdated. It probably isn't actually doing anything now actually and instead is using regular Picard behaviour. You'll get better results with regular Picard. To remove a source of conflict, I strongly suggest removing it and making sure you are using latest Picard.

Also worth noting that the Last.fm+ plugin can screw around with original release date for mp3s as well if you have the year tag enabled. It's flawed though, and I've been meaning to fix it for some time, just haven't got around to doing it.

xteejx wrote:

The problem is, a lot of remastered tracks have different audio fingerprints, and Picard doesn't seem to put the earliest /recorded/
date in, which is what I need it do to. i.e. The Beatles have a track remastered in 2000, but it's recorded in 1960-something.

Is there any way to use a plugin or tagger script of some kind to grab this data, or does it completely rely on relationships to work?

I'm afraid that there's no way to do this. To be technically correct, it'd have to get the recording date off the recording <-> work relationship (or at the very least pick the earliest release of the recording as a decent proxy as the vast, vast majority of recordings do not have known dates). Either choice would simply be too slow with the server implemented as it currently is, and the restriction to 1-second delay between requests to MB, as it'd have to request details for every track, one-by-one. Anyway, the overall feature you can track at http://tickets.musicbrainz.org/browse/PICARD-204

xteejx wrote:

I'm not sure the Original Release Date script goes through the relationships or search for the track and artist to /find/ this info.

The original plugin used release-level relationships. These relationships were deprecated with the introduction of release groups; and then NGS.

Picard since 0.15.1 uses the date of the earliest release in a release group; but it's obviously still album level - not an original recording release date so it doesn't work for tagging compilations.

Re: Earliest Recording Date help

Am using the latest Windows version, 1.0 I think. I don't have the last.fm year option enabled.

Will remove that Original Date plugin as suggested.

Hmm...so perhaps a good option would be to lower the matching accuracy to 80-90% and lower the weighting of compilations to 0?
Kind of assuming here that the singles and albums will be more likely to have correct original date relationships.

There IS an option that might work if a plugin/native option were to be developed.
To save load on the server, these kind of lookups could be restricted to users that have downloaded the MB database, or does
it currently not hold everything that would be required?

I'll keep an eye on that feature request on the tracker, it's one I'd /really/ love to see!

Thanks for the reply, really appreciate it. :)

Re: Earliest Recording Date help

Running your own server is possible, but the main difficulty is that parts of the web service need a lucene search server and index, and setting up this part of the server is very painful. You'd also have to monkey patch your way in to remove the throttling of requests as there's no "proper" way to do this currently.