KavalirOS/RockHeaven
1
0
Fork 0
Code Issues 2 Pull requests Projects Releases 88 Packages Wiki Activity Actions

Een lijsttrack krijgt zijn eigen jaar en zijn eigen plaat #63

Merged
roelof merged 1 commit from lijstcollectie-jaar-en-plaat into main 2026-08-06 11:38:32 +02:00
Conversation 0 Commits 1 Files changed 13 +813 -27
roelof commented 2026-08-06 11:35:30 +02:00
Owner
Copy link

Closes #62

Elk bestand in een collectie met de vorm flat komt binnen getagd voor de lijst en niet voor de track: album Top 2000, jaar 2024. Gemeten op schijf: 2000 van de 2000 én 500 van de 500 van de nieuwe Arrow Rock 500.

Het brancht op de vorm, niet op het type — de Arrow Rock 500 werd op de dag dat hij verscheen gedekt door dezelfde code.

De kern: het jaar altijd, de albumnaam vaak niet

Die asymmetrie is over dertig tracks gemeten voordat hij gekozen werd.

  • Het jaar komt er ongeveer vijf van de zes keer goed uit.
  • De albumnaam is de risicovolle helft: een bekend nummer leeft vooral op verzamelaars, dus een derde van de antwoorden noemt er een — Grandmix 2012, 15 Hollandse vakantiehits, Elvis 30 #1 Hits. De naam wordt daarom alleen overgenomen als het antwoord een studioalbum is, en anders houdt de track de lijstnaam. Dat is tenminste eerlijk over waar het bestand vandaan komt.

AlbumMatch draagt nu twee jaartallen: Year dateert de genoemde plaat, FirstYear is de vroegste van álle platen waar de opname op staat. Een latere verzamelaar kan die tweede nooit winnen. West End Girls leest Please 1986 voor de plaat en 1984 voor het nummer.

Twee gebreken in de opzoeking zelf, meegenomen

  • De strikte zoekopdracht laat een verzamelaar door. Die vraagt om primarytype:album AND -secondarytype:compilation, en voor West End Girls komt er precies één release-group terug: een hitmix uit 2002. Omdat dat een antwoord was werd de losse zoekopdracht nooit gedaan — waar Please en de single uit 1984 gewoon liggen. Dit helpt de RockHeaven-scan net zo goed.
  • FindListTrackAsync weegt beide zoekopdrachten samen in plaats van te stoppen bij de eerste die iets geeft, en probeert elke artiestspelling tegen elke titelverkorting. Te duur voor de scan, op zijn plaats voor een lijst: het zet Take It Easy op Eagles in plaats van op One of These Nights, en plaatst Ramses Shaffy & Liesbeth List & Alderliefste.

Last.fm als vangnet

Alleen gevraagd waar MusicBrainz de track onder geen enkele spelling kon plaatsen. Op de tracks die MusicBrainz wél plaatst is het de mindere: over dertig tracks noemden ze 8 keer dezelfde plaat en 20 keer niet, en dan verloor Last.fm meestal — het antwoordt met de plaat waaronder mensen scrobbelen, dus Redemption Song leest daar Legend en bij MusicBrainz Uprising.

Twee dingen om te weten:

  • Er zit geen uitgavedatum in het antwoord, wat de documentatie ook beweert. Hun eigen voorbeeld — Cher's Believe — geeft er geen, in XML noch in JSON. Het veld is jaren geleden uit de API gehaald en in de docs blijven staan.
  • Het id is dat van een release, niet van een release-group. De datum ervan is die van díé persing: Reise, Reise dateert zo op 2009 en de plaat is 2004. FindReleaseAsync haalt de release-group erbij.

Nagelopen

Wegwerp-PostgreSQL, twaalf echte Top 2000-bestanden, drie ronden:

ronde 1   10 gedateerd,  8 geplaatst, 1 via Last.fm, 2 niet gevonden
ronde 2    3 gedateerd,  1 geplaatst, 0 via Last.fm, 1 niet gevonden
ronde 3    0 gedateerd,  0 geplaatst, 0 via Last.fm, 1 niet gevonden

Negen van de twaalf staan op hun echte plaat — A Night at the Opera, Born in the U.S.A., Non-Stop Erotic Cabaret, Never for Ever, Nightflight to Venus, The Heist, …Like Clockwork, Je maintiendrai. Drie houden de lijstnaam, twee daarvan mét het goede jaar. Gé Reinders' "Bloasmuziek" kwam via Last.fm binnen op Blaos mich nao hoes, 2005 — precies waar het vangnet voor is.

Een herhaalde ronde schrijft geen enkel bestand: SaveListTrack schrijft alleen wat werkelijk verandert, dus de tracks die de lijstnaam hielden worden gelezen en niet herschreven.

Wat dit niet doet

De hoezen. Beide lijstcollecties dragen op elke track hetzelfde plaatje — het lijstlogo, geen platenhoes — en dat blijft zo: de albumreparatie overschrijft een bestaande hoes nooit. Dat is dezelfde kwaal een laag verder en verdient een eigen issue.

Closes #62 Elk bestand in een collectie met de vorm `flat` komt binnen getagd voor de **lijst** en niet voor de track: album `Top 2000`, jaar `2024`. Gemeten op schijf: 2000 van de 2000 én 500 van de 500 van de nieuwe Arrow Rock 500. Het brancht op de **vorm**, niet op het type — de Arrow Rock 500 werd op de dag dat hij verscheen gedekt door dezelfde code. ## De kern: het jaar altijd, de albumnaam vaak niet Die asymmetrie is over dertig tracks gemeten voordat hij gekozen werd. - Het **jaar** komt er ongeveer vijf van de zes keer goed uit. - De **albumnaam** is de risicovolle helft: een bekend nummer leeft vooral op verzamelaars, dus een derde van de antwoorden noemt er een — *Grandmix 2012*, *15 Hollandse vakantiehits*, *Elvis 30 #1 Hits*. De naam wordt daarom **alleen overgenomen als het antwoord een studioalbum is**, en anders houdt de track de lijstnaam. Dat is tenminste eerlijk over waar het bestand vandaan komt. `AlbumMatch` draagt nu twee jaartallen: `Year` dateert de genoemde plaat, `FirstYear` is de vroegste van álle platen waar de opname op staat. Een latere verzamelaar kan die tweede nooit winnen. *West End Girls* leest Please 1986 voor de plaat en 1984 voor het nummer. ## Twee gebreken in de opzoeking zelf, meegenomen - **De strikte zoekopdracht laat een verzamelaar door.** Die vraagt om `primarytype:album AND -secondarytype:compilation`, en voor *West End Girls* komt er precies één release-group terug: een hitmix uit 2002. Omdat dat een antwoord was werd de losse zoekopdracht nooit gedaan — waar Please en de single uit 1984 gewoon liggen. **Dit helpt de RockHeaven-scan net zo goed.** - **`FindListTrackAsync` weegt beide zoekopdrachten samen** in plaats van te stoppen bij de eerste die iets geeft, en probeert elke artiestspelling tegen elke titelverkorting. Te duur voor de scan, op zijn plaats voor een lijst: het zet *Take It Easy* op **Eagles** in plaats van op *One of These Nights*, en plaatst `Ramses Shaffy & Liesbeth List & Alderliefste`. ## Last.fm als vangnet Alleen gevraagd waar MusicBrainz de track onder geen enkele spelling kon plaatsen. Op de tracks die MusicBrainz wél plaatst is het de mindere: over dertig tracks noemden ze 8 keer dezelfde plaat en 20 keer niet, en dan verloor Last.fm meestal — het antwoordt met de plaat waaronder mensen *scrobbelen*, dus *Redemption Song* leest daar Legend en bij MusicBrainz Uprising. Twee dingen om te weten: - **Er zit geen uitgavedatum in het antwoord**, wat de documentatie ook beweert. Hun eigen voorbeeld — Cher's *Believe* — geeft er geen, in XML noch in JSON. Het veld is jaren geleden uit de API gehaald en in de docs blijven staan. - **Het id is dat van een release, niet van een release-group.** De datum ervan is die van díé persing: *Reise, Reise* dateert zo op 2009 en de plaat is 2004. `FindReleaseAsync` haalt de release-group erbij. ## Nagelopen Wegwerp-PostgreSQL, twaalf echte Top 2000-bestanden, drie ronden: ``` ronde 1 10 gedateerd, 8 geplaatst, 1 via Last.fm, 2 niet gevonden ronde 2 3 gedateerd, 1 geplaatst, 0 via Last.fm, 1 niet gevonden ronde 3 0 gedateerd, 0 geplaatst, 0 via Last.fm, 1 niet gevonden ``` Negen van de twaalf staan op hun echte plaat — A Night at the Opera, Born in the U.S.A., Non-Stop Erotic Cabaret, Never for Ever, Nightflight to Venus, The Heist, …Like Clockwork, Je maintiendrai. Drie houden de lijstnaam, twee daarvan mét het goede jaar. **Gé Reinders' "Bloasmuziek" kwam via Last.fm binnen** op *Blaos mich nao hoes*, 2005 — precies waar het vangnet voor is. Een herhaalde ronde schrijft **geen enkel bestand**: `SaveListTrack` schrijft alleen wat werkelijk verandert, dus de tracks die de lijstnaam hielden worden gelezen en niet herschreven. ## Wat dit niet doet De hoezen. Beide lijstcollecties dragen op elke track hetzelfde plaatje — het lijstlogo, geen platenhoes — en dat blijft zo: de albumreparatie overschrijft een bestaande hoes nooit. Dat is dezelfde kwaal een laag verder en verdient een eigen issue. 
Een collectie met de vorm flat is een aftelling — de Top 2000, de Arrow Rock
500 — en elk bestand erin komt binnen getagd voor de lijst en niet voor de
track: album "Top 2000", jaar 2024. Gemeten op schijf: 2000 van de 2000 en 500
van de 500, allebei. De jaarkolom las dus tweeduizend keer 2024.

ListRepairService is de tweede van de vijf stappen van de scanknop die tags
aanraakt: na de fill, vóór de albumreparatie, want zolang deze tracks niet op
echte platen staan kijkt die reparatie naar rijen die geen plaat zijn.

Het brancht op de vórm en niet op het type, dus de Arrow Rock 500 werd op de dag
dat hij verscheen gedekt door dezelfde code als de Top 2000.

Het jaar wordt altijd vervangen, de albumnaam vaak niet. Die asymmetrie is de
hele opzet, en is over dertig tracks gemeten voordat hij gekozen werd. Het jaar
komt er ongeveer vijf van de zes keer goed uit. De albumnaam is de risicovolle
helft: een bekend nummer leeft vooral op verzamelaars, dus een derde van de
antwoorden noemt er een — "Grandmix 2012", "15 Hollandse vakantiehits", "Elvis
30 #1 Hits". De naam wordt daarom alleen overgenomen als het antwoord een
studioalbum is, en anders houdt de track de lijstnaam, wat tenminste eerlijk is
over waar het bestand vandaan komt.

AlbumMatch draagt nu twee jaartallen. Year dateert de plaat die genoemd is;
FirstYear is de vroegste van alle platen waar de opname op voorkomt. Een latere
verzamelaar kan die tweede nooit winnen, en dat maakt hem de steviger van de
twee — "West End Girls" leest Please, 1986 voor de plaat en 1984 voor het
nummer. De albumreparatie wil de eerste, een lijst de tweede.

Twee dingen die de opzoeking zelf mankeerde en die hier zijn rechtgezet:

- De strikte zoekopdracht vraagt om primarytype:album AND -secondarytype:
  compilation, en MusicBrainz laat er toch een door. Voor "West End Girls" komt
  precies één release-group terug, een hitmix uit 2002 — en omdat dat een
  antwoord was, werd de losse zoekopdracht nooit gedaan, waar Please en de
  single uit 1984 gewoon liggen. Een verzamelaar is geen antwoord op die vraag.
  Dat helpt de RockHeaven-scan net zo goed.
- FindListTrackAsync weegt beide zoekopdrachten samen in plaats van te stoppen
  bij de eerste die iets geeft, en probeert elke artiestspelling tegen elke
  titelverkorting. Dat is te duur voor de scan en op zijn plaats voor een lijst:
  het zet de Eagles' "Take It Easy" op Eagles in plaats van op One of These
  Nights, en plaatst "Ramses Shaffy & Liesbeth List & Alderliefste".

Last.fm is het vangnet en verder niets. Het wordt alleen gevraagd waar
MusicBrainz de track onder geen enkele spelling kon plaatsen, want op de tracks
die MusicBrainz wél plaatst is het de mindere van de twee: over dertig tracks
noemden ze acht keer dezelfde plaat en twintig keer niet, en dan verloor Last.fm
meestal — het antwoordt met de plaat waaronder mensen scrobbelen, dus
"Redemption Song" leest daar Legend en bij MusicBrainz Uprising. Waar het wel
goed voor is, is een plaat die de zoekopdracht helemaal niet bereikt.

Twee dingen om te weten over die dienst. Er zit geen uitgavedatum in het
antwoord, wat de documentatie ook beweert: hun eigen voorbeeld, Cher's Believe,
geeft er geen, in XML noch in JSON. En het id dat terugkomt is dat van een
release, niet van een release-group, dus de datum ervan is die van díé persing —
Reise, Reise dateert zo op 2009 en de plaat is 2004. FindReleaseAsync haalt de
release-group erbij en leest daar de eerste verschijningsdatum.

Nagelopen tegen een wegwerpdatabase met twaalf echte Top 2000-bestanden:

  ronde 1   10 gedateerd,  8 geplaatst, 1 via Last.fm, 2 niet gevonden
  ronde 2    3 gedateerd,  1 geplaatst, 0 via Last.fm, 1 niet gevonden
  ronde 3    0 gedateerd,  0 geplaatst, 0 via Last.fm, 1 niet gevonden

Negen van de twaalf staan op hun echte plaat, drie houden de lijstnaam en twee
daarvan kregen wel het goede jaar. Gé Reinders' "Bloasmuziek" kwam via Last.fm
binnen op "Blaos mich nao hoes", 2005. Een herhaalde ronde schrijft geen enkel
bestand: SaveListTrack schrijft alleen wat werkelijk verandert.

Closes #62

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
roelof merged commit 9e6db96962 into main 2026-08-06 11:38:32 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
KavalirOS/RockHeaven!63
No description provided.