-
-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adapt CSV output format to match with SUISA Tarif S (2020-2023) #187
Comments
I'm already on a large PR to take care of a lot of this.
I have been assuming that we leave
I can dig up official lists from sources like EBU/ETSI, but we don't currently have any such dava available from acr cloud so i wouldn't dig too deep All the other points are pretty much what i also discovered, but from a purely technical perspective probably ignoreable-ish. Like i said, been hacking... what my working copy has generates what is now in #188 and this CSV (with a filename of
I'm at the point where i'm finalising the thing for a PR, so we'll be able to reason over this in code soon :) Main difference to this proposal is that the field "Identifikationsnummer" is called "vom Sender der Aufnahme selbst zugewiesene Identifikationsnummer" in my implementation. The implementation adds all fields, and fills them in where i noticed we have data available if possible but the main focus is still on those mentions in "Buchstabe G" explicitly. I also stop guessing that we could just do artist = composer if no compose data is available. |
I would assert the document is indeed still valid, if not we would have gotten a letter a year ago (ein Jahr vor Ablauf). The fact that it's still what we find via their webinterface and we were told to "look at the tariff" compounds this. Looking forward, according to "automatisch um jeweils ein Jahr bis längstens 31. Dezember 2025" we either get a letter on 31. Dec 2023 (this year) or we are in default clause territory anyway and there will most likely be a new "Gemeinsamer Tarif S 2025 – 2028" that we would then assume to be valid through to 2030. For these reasons imma mark this preliminary clarification as clarified. |
my understanding is IMO the legalese sounding part is what Eidgenössische Schiedskommission für die Verwertung von Urheber- |
"Anhang 1" has us covered: lol, the xlsx file downloadable from here only has "Name des Files: SENDER_JAHR_MONAT" in that comment, but it's also named "Vorlage_fuer_Sendemeldungen__GTS__2020-2022.xlsx" for whatever reasons. |
The idea was to clarify the topics officially with SUISA instead of assuming that the interpretation will be correct, this didn't worked out in the past. The description of the issue has all relevant parts from the documents and templates. |
The current implementation was not based on assumptions but rather on clarifying the topics officially with SUISA. It's rather clear that the staff at SUISA said it's ok when that was clearly not the case in the past... anyways, an initial implementation that addresses this is in #189 and can be finalized if we get any legally sound feedback directly. please let me know in time (before feb) if we need to defer sending this months report to a later date. We are required to send it in the following month and currently do so on the first business day of the sais month, in theory this means we can defer sending it until the end of Feb (i'm not proposing end of month as new standard here, this would just be for the Jan 2023 report). |
Update after clarifications with SUISA as of 2023-02
Yes the Tarif is still valid for 2023 as confirmed by SUISA on 2023-02-02
The field has to be provided and is named
Yes, all fields are expected, but only values for the mandatory ones must be provided, the format and field ordering must be based on the Vorlage für Sendemeldungen: Gemeinsamer Tarif S
SUISA expects the report in XLSX format for 2023 based on the Vorlage für Sendemeldungen: Gemeinsamer Tarif S and not CSV anymore, addressed in #203 |
btw, the International Standard Recording Code (ISRC) Handbook – 4th Edition, 2021 has this on compliant ISRC codes (emphasis mine):
One could construe that the reference metadata fields should thus be considered optional from our reporting perspective in cases where we provide an ISRC. An argument that could be made revolves around privacy, the way that ISRC codes are structured it would very well be possible to report on tracks so they get assigned properly to a label without more detail. imo, it shouldn't be up to us to decide what title or name is associated with any given ISRC as this information might be privy to only the registrant and still be compliant with the spec the handbook describes. I assume that suisa will have contracts in place that require an isrc registrant to provide them with metadata as they are a relevant repertoire database, but this is just me assuming. I don't think we are part of that agreement and, security wise, it would be nice if we didn't have to handle data that isn't ours (esp. given new data privacy laws and the fact that the artist field might contain pii). anyways, maybe a privacy centric argument can help our case. also, the handbook i linked is an interesting read |
Update after clarifications with SUISA as of 2023-02
Yes, that's correct. Note regarding the fields
An empty value is expected. |
Overview
The CSV output shall be adapted to match with the SUISA document Gemeinsamer Tarif S 2020 – 2023, as published on the SUISA Radio and TV page.
Background
The following parts are relevant from the Gemeinsamer Tarif S 2020 – 2023 document:
G. Verzeichnisse (click to expand)
Anhang I - Vorlage Formatierung Sendelisten Radio (click to expand)
The referenced Anhang I (appendix I) within paragraph 33, named "Vorlage Formatierung Sendelisten Radio", contains the fields in the following order:
Titel
Komponist
Interpret
Interpreten-Info
Sender
Sendedatum
Sendedauer
Sendezeit
Werkverzeichnisangaben
ISRC
Label
CD ID / Katalog-Nummer
Aufnahmedatum
Aufnahmeland
Erstveröffentlichungsdatum
Titel des Tonträgers (Albumtitel)
Autor Text
Track Nummer
Genre
Programm
Bestellnummer
Marke
Label Code
EAN/GTIN
interestingly it lacks a field corresponding to "vom Sender der Aufnahme selbst zugewiesene Identifikationsnummer" according to paragraph 34.
There's an additional template called Vorlage für Sendemeldungen: Gemeinsamer Tarif S:
Identifikationsnummer
which matches with the mentioned data "vom Sender der Aufnahme selbst zugewiesene Identifikationsnummer" of paragraph 34, which is missing in Anhang I.except foralthoughLabel Code
, which is probably only a formatting error, as it's not mentioned in paragraph 34Label
andLabel Code
are marked as mandatory, only one is required according to clarifications with SIUSA as of 2023-02)Hypothesis: The data under paragraph 34 is mandatory, whereas all the other data can be considered optional.
This would imply that at least the following fields with the names below, have to be provided:
Titel
: Titel sind in Orginalsprache gemäss Tonträger, inklusive ggf. Versionsabgaben ("live in London" "dirty remix" etc.) anzugebenKomponist
: Name des/der KomponistenInterpret
: Name des (Haupt-) Interpreten, bzw. GruppennameSendedatum
: Datum der Nutzung im Einheitformat, z.B. YYYYMMDD - 20110101Sendedauer
: Dauer der Nutzung im Einheitsformat, z.B. hh:mm:ss - 00:03:54Sendezeit
: Startzeitpunkt der Nutzung im Einheitsformat, z.B. hh:mm:ss - 06:09:13ISRC
: ISRC Code des QuelltonträgersLabel
: Name des LabelsIdentifikationsnummer
: Vom Sender der Aufnahme selbst zugewiesene IdentifikationsnummerThe header of the current CSV output looks as follows and currently doesn't exactly match with the fields from the template:
Proposal
To match with the template from the Gemeinsamer Tarif S 2020 – 2023 document the CSV header and field ordering shall be adapted as follows:
Künstler
👉Interpret
Identifikationsnummer
the PR feat: add CRID as Identifikationsnummer #185 could be usedAdditionally, the date format of the
Sendedatum
shall be changed fromDD/MM/YY
toYYYYMMDD
in order to match with the example from the template.The name of the CSV file shall be changed from
suisa_sendemeldung_<MONTH>.csv
to<RADIO-STATION>_<YYYY>_<MM>.csv
(e.g.my-station_2023_01.csv
), in order to match with the naming convention of Anhang I.Preliminary clarifications
Before the change can be made, the following preliminary clarifications should be made with SUISA:
Is the Gemeinsamer Tarif S 2020 – 2023 document still valid for 2023, or is there a newer superseding one?
Gültigkeitsdauer (click to expand)
Is the assumption correct, that the fields corresponding to the data mentioned in paragraph 34 are mandatory and everything else is optional?
Why is the there no field matching the data "vom Sender der Aufnahme selbst zugewiesene Identifikationsnummer" reference within paragraph 34, in Anhang I?
Does SUISA expect the report to contain all fields from the template or only the mandatory ones?
What value is expected in case a certain field is not applicable ("Sofern zutreffend/bekannt"), e.g. empty value or
N/A
?Is it still OK to deliver the report as CSV or is an XLSX format (same as the template) required?
Request approved example entries for multiple genres (rock/pop, classic, jazz and electronics as well as jingles)
The text was updated successfully, but these errors were encountered: