Tango.info music track date: Difference between revisions

From tango.info wiki
Jump to navigation Jump to search
 
(11 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[category:data]]
[[Category:Tango.info]]
[[category:tango.info]]


==Proposal==
==Meaning of the value==
Then we have invalidation of interpreting equality in imprecise date e.g.
It could mean date of
* performance (Note: some tracks may contain audio from performances that occurred on different dates, for an example see: [[Gardel playback]])
* fixation
* creation of the recording
* creation of the first published recording of one fixation
* publication
 
claim of unknown source: "Record companies record on one day and release on a later day, perhaps year. Nowadays the date on the media is the date of RELEASE."
 
==Issue of ambiguity of imprecise date==
 
https://tango.info/02480002030065-1-1 says
 
 #      Orchestra       Vocalists       Rec. Date       Track Qty
 1      Juan D'Arienzo  Carlos Dante    1928    4
 
but http://users.telenet.be/tangoteca/darienzo/index.html says this was
"recorded twice in that same year"... meaning two separate performances. tango.info's performance asssignment may hence be false.
 
So, we have invalidation of interpreting equality in imprecise date e.g.
YYYY.
YYYY.
===Proposed remedy===


I suggest this solution:
I suggest this solution:
Line 17: Line 37:
==OLD==
==OLD==
THIS PAGE IS _NOT_ UP TO DATE
THIS PAGE IS _NOT_ UP TO DATE
Is this a proposal or current policy?? [[User:Chrisjjj|Chrisjjj]] 2010-11-24T22:49:32 (UTC)
* DON'T include dates unless you have at least the year (e.g., 1953-00-00)
* DON'T include dates unless you have at least the year (e.g., 1953-00-00)
* Use a range [1939--1964] if the recording could be ANY recording within that range
* Use a range [1939--1964] if the recording could be ANY recording within that range
Line 25: Line 48:
** 00-00 allows searching
** 00-00 allows searching
** ? 00-00 is used for "known" uncomplete, i.e. there is no better information found for this performance, e.g. early D'Arienzo. Opposed to marking with "1960", where only tango.info lacks the information for that track row, but if tango.info does some work it can be extended.
** ? 00-00 is used for "known" uncomplete, i.e. there is no better information found for this performance, e.g. early D'Arienzo. Opposed to marking with "1960", where only tango.info lacks the information for that track row, but if tango.info does some work it can be extended.
==Problems==
==Problems==
* Winamp only shows the first four characters, so there's a lot of ambiguity here for Winamp users.
* Winamp only shows the first four characters, so there's a lot of ambiguity here for Winamp users. MediaMonkey too [[User:Chrisjjj|Chrisjjj]]
** The tagger should have an option for save(secure)-date e.g. spit out only year or year-month or year-month-day
** The tagger should have an option for save(secure)-date e.g. spit out only year or year-month or year-month-day
*** what is save/secure "date"? if it means same date contained in a listing of performances than such listing is needed

Latest revision as of 2017-08-27T18:38:23


Meaning of the value

It could mean date of

  • performance (Note: some tracks may contain audio from performances that occurred on different dates, for an example see: Gardel playback)
  • fixation
  • creation of the recording
  • creation of the first published recording of one fixation
  • publication

claim of unknown source: "Record companies record on one day and release on a later day, perhaps year. Nowadays the date on the media is the date of RELEASE."

Issue of ambiguity of imprecise date

https://tango.info/02480002030065-1-1 says

 #      Orchestra       Vocalists       Rec. Date       Track Qty  1      Juan D'Arienzo  Carlos Dante    1928    4

but http://users.telenet.be/tangoteca/darienzo/index.html says this was "recorded twice in that same year"... meaning two separate performances. tango.info's performance asssignment may hence be false.

So, we have invalidation of interpreting equality in imprecise date e.g. YYYY.

Proposed remedy

I suggest this solution:

  1. redefine the DB track date to allow disambiguator e.g. 1928(1), 1928(2 (MySQL permitting)
  2. Declare this in policy, explaining that 1928(1) != 1928(2)
  3. Use the disam form in web display
  4. make tagger %date% deliver the ambiguous pure date form e.g. 1928
  5. in tagger provide %date_disam% providing the disam form.
  6. make data input sue the disam form.

OLD

THIS PAGE IS _NOT_ UP TO DATE

Is this a proposal or current policy?? Chrisjjj 2010-11-24T22:49:32 (UTC)

  • DON'T include dates unless you have at least the year (e.g., 1953-00-00)
  • Use a range [1939--1964] if the recording could be ANY recording within that range
  • Use likely matches only (you have this in some cases now, e.g., 1930--1940--1945)
  • Use something to indicate that a date does NOT match a recording, e.g., !1939
  • Wouldn't it make better sense to store years without 00-00?
    • then it would be a valid date (year)
    • 00-00 allows searching
    • ? 00-00 is used for "known" uncomplete, i.e. there is no better information found for this performance, e.g. early D'Arienzo. Opposed to marking with "1960", where only tango.info lacks the information for that track row, but if tango.info does some work it can be extended.

Problems

  • Winamp only shows the first four characters, so there's a lot of ambiguity here for Winamp users. MediaMonkey too Chrisjjj
    • The tagger should have an option for save(secure)-date e.g. spit out only year or year-month or year-month-day
      • what is save/secure "date"? if it means same date contained in a listing of performances than such listing is needed