Tango.info music track date: Difference between revisions

From tango.info wiki
Jump to navigation Jump to search
 
Line 19: Line 19:


but http://users.telenet.be/tangoteca/darienzo/index.html says this was
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 perfroamnce asssignment may hence be false.
"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.
So, we have invalidation of interpreting equality in imprecise date e.g.

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