Het logo van een lijst is geen platenhoes #74

Merged

roelof merged 1 commit from lijstlogo-en-collectieplaatje into main

2026-08-06 16:29:20 +02:00

roelof commented

2026-08-06 16:28:13 +02:00

Owner

Closes #64
Closes #71

De twee moesten samen. collections/{id}/image gaf de hoes van de eerste track terug, wat voor een lijstcollectie toevallig het logo was — elk bestand droeg het. Zodra #64 daar echte sleeves in zet, wordt dat één willekeurige plaat. #64 alleen doen zou dus een verslechtering zijn geweest.

#64 — het logo herkennen

Elk bestand van een collectie met de vorm flat draagt het plaatje van de lijst als albumhoes. Gemeten: precies één afbeelding over alle 2000 bestanden van de Top 2000 en alle 500 van Arrow Rock, en byte voor byte gelijk aan de rockheaven.jpg die naast de descriptor ligt.

Voor de albumreparatie waren die 2500 bestanden dus compleet en bereikten ze geen enkele stap. Ze tellen nu als hoesloos, en de gewone keten doet de rest.

De toets is exact en geen gok: AlbumTags.CoverKey noemt de bytes van de hoes en het collectiebestand die van zichzelf. Een plaat waarvan de sleeve werkelijk het logobestand van een lijst is, bestaat niet. Dit is ook de enige plek hier die een bestaande hoes overschrijft — hem laten staan zou juist het plaatje laten staan dat de ronde probeert te vervangen.

#71 — het collectieplaatje

Het endpoint serveert nu rockheaven.jpg zelf, met terugval op het oude antwoord voor een collectie die het bestand niet heeft — juist voor de soorten waarvan het plaatje dat van het volume of van de plaat is. De desktopspeler toont het naast de collectierij in de artiestenlijst en in het paneel eronder; de webspeler en de telefoon vroegen dat endpoint al en hoefden niets.

Nagelopen

Wegwerpdatabase met een lijstcollectie en een albumcollectie die dezelfde plaat houden:

lijstreparatie      2 gedateerd, 2 geplaatst
albumreparatie      1 record, 2 hoezen gezet
tweede ronde        alles nul

De twee lijstbestanden droegen het logo (feb161a211) en dragen nu de echte sleeve van Kill 'Em All — bekeken en bevestigd. Het endpoint geeft voor de lijstcollectie het logo terug, gelijk aan het bestand op schijf, en voor de albumcollectie nog steeds de hoes van de eerste track.

Eén ding dat opviel en hier niet in zit

De lijsttracks landden niet op de albumrij die de Albums-collectie al had. Twee rijen voor dezelfde plaat:

Kill 'Em All   (rechte apostrof, uit de tags)        10 tracks, Testalbums
Kill ’Em All   (typografische, uit MusicBrainz)       2 tracks, Testlijst

citext is hoofdletterongevoelig maar niet leestekenongevoelig. Gevolg: de hoes kon niet geleend worden en moest bij fanart.tv gehaald worden, en in een albumlijst staat die plaat twee keer. De uitkomst klopt, maar het kost een verzoek waar het gratis had gekund. MusicBrainzService.Fold doet precies deze vouwing al voor het vergelijken; wat er ontbreekt is dezelfde vouwing bij het opslaan van een albumtitel. Verdient een eigen issue.

Closes #64 Closes #71 **De twee moesten samen.** `collections/{id}/image` gaf de hoes van de eerste track terug, wat voor een lijstcollectie toevallig het logo *was* — elk bestand droeg het. Zodra #64 daar echte sleeves in zet, wordt dat één willekeurige plaat. #64 alleen doen zou dus een verslechtering zijn geweest. ## #64 — het logo herkennen Elk bestand van een collectie met de vorm `flat` draagt het plaatje van de lijst als albumhoes. Gemeten: **precies één afbeelding** over alle 2000 bestanden van de Top 2000 en alle 500 van Arrow Rock, en byte voor byte gelijk aan de `rockheaven.jpg` die naast de descriptor ligt. Voor de albumreparatie waren die 2500 bestanden dus compleet en bereikten ze geen enkele stap. Ze tellen nu als hoesloos, en de gewone keten doet de rest. De toets is **exact en geen gok**: `AlbumTags.CoverKey` noemt de bytes van de hoes en het collectiebestand die van zichzelf. Een plaat waarvan de sleeve werkelijk het logobestand van een lijst is, bestaat niet. Dit is ook de enige plek hier die een bestaande hoes **overschrijft** — hem laten staan zou juist het plaatje laten staan dat de ronde probeert te vervangen. ## #71 — het collectieplaatje Het endpoint serveert nu `rockheaven.jpg` zelf, met terugval op het oude antwoord voor een collectie die het bestand niet heeft — juist voor de soorten waarvan het plaatje dat van het volume of van de plaat is. De **desktopspeler** toont het naast de collectierij in de artiestenlijst en in het paneel eronder; de webspeler en de telefoon vroegen dat endpoint al en hoefden niets. ## Nagelopen Wegwerpdatabase met een lijstcollectie en een albumcollectie die dezelfde plaat houden: ``` lijstreparatie 2 gedateerd, 2 geplaatst albumreparatie 1 record, 2 hoezen gezet tweede ronde alles nul ``` De twee lijstbestanden droegen het logo (`feb161a211`) en dragen nu de echte sleeve van *Kill 'Em All* — bekeken en bevestigd. Het endpoint geeft voor de lijstcollectie het logo terug, gelijk aan het bestand op schijf, en voor de albumcollectie nog steeds de hoes van de eerste track. ## Eén ding dat opviel en hier niet in zit De lijsttracks landden **niet** op de albumrij die de Albums-collectie al had. Twee rijen voor dezelfde plaat: ``` Kill 'Em All (rechte apostrof, uit de tags) 10 tracks, Testalbums Kill ’Em All (typografische, uit MusicBrainz) 2 tracks, Testlijst ``` `citext` is hoofdletterongevoelig maar niet leestekenongevoelig. Gevolg: de hoes kon niet geleend worden en moest bij fanart.tv gehaald worden, en in een albumlijst staat die plaat twee keer. De uitkomst klopt, maar het kost een verzoek waar het gratis had gekund. `MusicBrainzService.Fold` doet precies deze vouwing al voor het *vergelijken*; wat er ontbreekt is dezelfde vouwing bij het *opslaan* van een albumtitel. Verdient een eigen issue.

roelof added 1 commit

2026-08-06 16:28:13 +02:00

Het logo van een lijst is geen platenhoes a104de699b

Elk bestand van een collectie met de vorm flat draagt het plaatje van de lijst
als albumhoes. Niet bij benadering: precies één afbeelding over alle 2000
bestanden van de Top 2000 en alle 500 van Arrow Rock, byte voor byte hetzelfde,
en byte voor byte gelijk aan de rockheaven.jpg die naast de descriptor ligt.

Voor de albumreparatie waren die 2500 bestanden dus compleet en bereikten ze
geen enkele stap. Ze tellen nu als hoesloos, en de gewone keten doet de rest:
lenen van een andere track van dezelfde plaat, dan MusicBrainz, dan fanart.tv.

De toets is exact en geen gok. AlbumTags.CoverKey noemt de bytes van de hoes en
het collectiebestand noemt die van zichzelf; een plaat waarvan de sleeve
werkelijk het logobestand van een lijst is, bestaat niet. Dit is ook de enige
plek hier die een bestaande hoes overschrijft, want hem laten staan zou juist
het plaatje laten staan dat de ronde probeert te vervangen.

En daarmee moest #71 mee, anders was het een verslechtering: collections/{id}
/image gaf de hoes van de eerste track terug, wat voor een lijst toevallig het
logo wás. Zodra er echte sleeves in die bestanden staan is dat één willekeurige
plaat. Het endpoint serveert nu rockheaven.jpg zelf, met terugval op het oude
antwoord voor een collectie die het bestand niet heeft — juist voor de soorten
waarvan het plaatje dat van het volume of van de plaat is.

De desktopspeler toont het nu naast de collectierij in de artiestenlijst en in
het paneel eronder, waar de andere twee vormen een volumeplaatje of een portret
tonen. De webspeler en de telefoon vroegen dat endpoint al en hoefden niets.

Nagelopen tegen een wegwerpdatabase met een lijstcollectie en een
albumcollectie die dezelfde plaat houden:

  lijstreparatie      2 gedateerd, 2 geplaatst
  albumreparatie      1 record, 2 hoezen gezet
  tweede ronde        alles nul

De twee lijstbestanden droegen het logo (feb161a211) en dragen nu de echte
sleeve van Kill 'Em All, bekeken en bevestigd. Het endpoint geeft voor de
lijstcollectie het logo terug, gelijk aan het bestand op schijf, en voor de
albumcollectie nog steeds de hoes van de eerste track.

Closes #64
Closes #71

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>