Problem with definitions of TPUB and TCOP, and the lack of a separate field for "Record Label"

[Steven Saffer]

Hi,

Please see below e-mail I sent to Dan O'Neill, who has requested I send it
to the list.

There are two issues, namely with the definitions of the TCOP field and the
TPUB field, but the more urgent issue is with the definition of the TPUB
field:

Definition of the TPUB field as "Label or Publisher" is problematic. There
needs to be a specific field for the label ­ see below for explanation.

Thanks,

Steven

Steven Saffer B.E.Sc (EE), MBA
President
Abbeywood Records
t: [phone]
f: [phone]
c: [phone]
***@abbeywoodrecords.com
http://abbeywoodrecords.com <http://abbeywoodrecords.com/>
________________________

Dear Dan,

Thanks for the prompt reply. I'm pleased to be on the list, especially
since I have been involved in other standards groups, as a developer at
the audio company TC Electronic, and an executive at TC Applied
Technologies (http://tctechnologies.tc <http://tctechnologies.tc/> ). Now
running a record label, we
have noticed that many of our partners are now asking for tagged mp3s of
our catalog. I started digging into the spec as a result of uncovering
differences in how these fields have been interpreted by developers of
tagging apps, specifically MusicBrainz Picard and MP3Tag.

As relates to TPUB, the issues I am seeing seem to be as a result of the
very loose definition of the TPUB field ("either label OR publisher"), and
also as a result of the lack of specifics around the TCOP field. Picard
interprets and displays the TPUB field as the name of the label, whereas
MP3Tag (and other tagging apps) display it as "Publisher".

These differences will have a significant impact on the enforcing of
copyright and the payment of royalties to artists, labels and publishers,
specifically as relates to the reporting of usage to performing rights
(and other) societies. For example, when an MP3 is submitted to an
internet radio station that decides to use the included metadata to report
to Soundexchange (the organization that collects money on behalf of
featured performers), the label information is used. If the name of the
publisher is used, there is a risk that the label will not see these
royalties. There needs to be a separate field for the label name.

A distinction needs to be made between the sound recording copyright owner
(could be the same as the label but in case the content is licensed, that
will not be
the case), and the copyright in the composition (the publisher), and
perhaps an additional field is necessary, as well as a clearer description
of what these fields should contain. Although the description in the spec
as relates to the TCOP field would seem to suggest that the name of the
sound recording copyright owner is included in this field, it is not
clearly defined and may be misunderstood by developers. Another source of
confusion is that it is not clear whether the application should prefix
the copyright field with the (C) symbol when displaying the information,
or the person tagging should include the (C) symbol. It is also unclear
whether the year should be included in the field itself when the recording
is tagged, or this field will be prefixed with the data in the 'year'
field when the metadata is displayed, or it will be displayed in the field
heading in the app.

As relates to the TPUB field, the label may be the same as the publisher,
but typically they are different. As we see broader adoption of the
standard and use of the metadata by the music industry, these are issues
that should be dealt with now.

Let me know if there is anything else you need, and if there are any
upcoming meetings where this issue might be discussed.

Looking forward to hearing from you.

Best regards,

Steven

Steven Saffer B.E.Sc (EE), MBA
President
Abbeywood Records
t: [phone]
f: [phone]
c: [phone]
***@abbeywoodrecords.com
http://abbeywoodrecords.com <http://abbeywoodrecords.com/>

[Peter Bennett]

Since nobody has responded I will give my opinions on this.
The ID3 standard is very loosely applied and there is not really any
governing body.
Most applications are using ID3v2.3. ID3v2.4 is out there, but since
many applications and hardware devices do not support it, it is not very
useful. The same will apply to any new changes proposed.
Also, bear in mind that there is nothing to stop people from modifying
or removing the ID3 tags from a file.
There are many mp3 files out there with invalid tags, incorrect data in
frames, and tags formatted wrongly.
I think the best is for you to agree on a format with your customers,
and hopefully they will then got to other suppliers and get the
convention more widely followed.
If there are not frames for what you need, you can create your own User
defined text information frame (TXXX). There can be as many of these as
you need, each one with a unique description. You can use your web
address or domain in the description to keep it distinct from frames
used by others.
As far as the TCOP frame is concerned, the definition in ID3V2.3 is
rather vague, as you mentioned, but the ID3v2.4 definition adds some
standards:

The 'Copyright message' frame, in which the string must begin with a
year and a space character (making five characters), is intended for
the copyright holder of the original sound, not the audio file
itself. The absence of this frame means only that the copyright
information is unavailable or has been removed, and must not be
interpreted to mean that the audio is public domain. Every time this
field is displayed the field must be preceded with "Copyright " (C) "
", where (C) is one character showing a C in a circle.

You could use this definition with ID3v2.3 because it will still fit
the ID3v2.3 standard, and add some structure to the frame data.

The Publisher frame which could be label or publisher - you will have to
agree on some convention, probably putting the label in TPUB is most useful.

Let me know if I can assist with any implementation details, Jampal has
some features that may make things easier for you, like mass tagging of
files, supporting user defined tags, batch processing.

Regards
Peter Bennett
(Music lover and author of Jampal)

Post by Steven Saffer
Hi,
Please see below e-mail I sent to Dan O'Neill, who has requested I
send it to the list.
There are two issues, namely with the definitions of the TCOP field
and the TPUB field, but the more urgent issue is with the definition
Definition of the TPUB field as "Label or Publisher" is problematic.
There needs to be a specific field for the label -- see below for
explanation.
Thanks,
Steven
Steven Saffer B.E.Sc (EE), MBA
President
Abbeywood Records
t: [phone]
f: [phone]
c: [phone]
http://abbeywoodrecords.com <http://abbeywoodrecords.com/>
________________________
Dear Dan,
Thanks for the prompt reply. I'm pleased to be on the list, especially
since I have been involved in other standards groups, as a developer at
the audio company TC Electronic, and an executive at TC Applied
Technologies (http://tctechnologies.tc <http://tctechnologies.tc/>).
Now running a record label, we
have noticed that many of our partners are now asking for tagged mp3s of
our catalog. I started digging into the spec as a result of uncovering
differences in how these fields have been interpreted by developers of
tagging apps, specifically MusicBrainz Picard and MP3Tag.
As relates to TPUB, the issues I am seeing seem to be as a result of the
very loose definition of the TPUB field ("either label OR publisher"), and
also as a result of the lack of specifics around the TCOP field. Picard
interprets and displays the TPUB field as the name of the label, whereas
MP3Tag (and other tagging apps) display it as "Publisher".
These differences will have a significant impact on the enforcing of
copyright and the payment of royalties to artists, labels and publishers,
specifically as relates to the reporting of usage to performing rights
(and other) societies. For example, when an MP3 is submitted to an
internet radio station that decides to use the included metadata to report
to Soundexchange (the organization that collects money on behalf of
featured performers), the label information is used. If the name of the
publisher is used, there is a risk that the label will not see these
royalties. There needs to be a separate field for the label name.
A distinction needs to be made between the sound recording copyright owner
(could be the same as the label but in case the content is licensed,
that will not be
the case), and the copyright in the composition (the publisher), and
perhaps an additional field is necessary, as well as a clearer description
of what these fields should contain. Although the description in the spec
as relates to the TCOP field would seem to suggest that the name of the
sound recording copyright owner is included in this field, it is not
clearly defined and may be misunderstood by developers. Another source of
confusion is that it is not clear whether the application should prefix
the copyright field with the (C) symbol when displaying the information,
or the person tagging should include the (C) symbol. It is also unclear
whether the year should be included in the field itself when the recording
is tagged, or this field will be prefixed with the data in the 'year'
field when the metadata is displayed, or it will be displayed in the field
heading in the app.
As relates to the TPUB field, the label may be the same as the publisher,
but typically they are different. As we see broader adoption of the
standard and use of the metadata by the music industry, these are issues
that should be dealt with now.
Let me know if there is anything else you need, and if there are any
upcoming meetings where this issue might be discussed.
Looking forward to hearing from you.
Best regards,
Steven
Steven Saffer B.E.Sc (EE), MBA
President
Abbeywood Records
t: [phone]
f: [phone]
c: [phone]
http://abbeywoodrecords.com <http://abbeywoodrecords.com/>

[Jud White]

imho TPUB = Record Label. I've implemented it this way for years on
suggestion and no complaints so far. It also kind of makes sense, for
example Morton Publishing Company (a book publisher) serves a similar
function to a record label. The copyright holder may be the record label,
or the artist may retain rights, and the copyright holder could change.

Post by Peter Bennett
Since nobody has responded I will give my opinions on this.
The ID3 standard is very loosely applied and there is not really any
governing body.
Most applications are using ID3v2.3. ID3v2.4 is out there, but since many
applications and hardware devices do not support it, it is not very useful.
The same will apply to any new changes proposed.
Also, bear in mind that there is nothing to stop people from modifying or
removing the ID3 tags from a file.
There are many mp3 files out there with invalid tags, incorrect data in
frames, and tags formatted wrongly.
I think the best is for you to agree on a format with your customers, and
hopefully they will then got to other suppliers and get the convention more
widely followed.
If there are not frames for what you need, you can create your own User
defined text information frame (TXXX). There can be as many of these as you
need, each one with a unique description. You can use your web address or
domain in the description to keep it distinct from frames used by others.
As far as the TCOP frame is concerned, the definition in ID3V2.3 is rather
The 'Copyright message' frame, in which the string must begin with a
year and a space character (making five characters), is intended for
the copyright holder of the original sound, not the audio file
itself. The absence of this frame means only that the copyright
information is unavailable or has been removed, and must not be
interpreted to mean that the audio is public domain. Every time this
field is displayed the field must be preceded with "Copyright " (C) "
", where (C) is one character showing a C in a circle.
You could use this definition with ID3v2.3 because it will still fit the
ID3v2.3 standard, and add some structure to the frame data.
The Publisher frame which could be label or publisher - you will have to
agree on some convention, probably putting the label in TPUB is most useful.
Let me know if I can assist with any implementation details, Jampal has
some features that may make things easier for you, like mass tagging of
files, supporting user defined tags, batch processing.
Regards
Peter Bennett
(Music lover and author of Jampal)
Hi,
Please see below e-mail I sent to Dan O'Neill, who has requested I send
it to the list.
There are two issues, namely with the definitions of the TCOP field and
the TPUB field, but the more urgent issue is with the definition of the
Definition of the TPUB field as "Label or Publisher" is problematic.
There needs to be a specific field for the label – see below for
explanation.
Thanks,
Steven
Steven Saffer B.E.Sc (EE), MBA
President
Abbeywood Records
t: [phone]
f: [phone]
c: [phone]
http://abbeywoodrecords.com
________________________
Dear Dan,
Thanks for the prompt reply. I'm pleased to be on the list, especially
since I have been involved in other standards groups, as a developer at
the audio company TC Electronic, and an executive at TC Applied
Technologies (http://tctechnologies.tc). Now running a record label, we
have noticed that many of our partners are now asking for tagged mp3s of
our catalog. I started digging into the spec as a result of uncovering
differences in how these fields have been interpreted by developers of
tagging apps, specifically MusicBrainz Picard and MP3Tag.
As relates to TPUB, the issues I am seeing seem to be as a result of the
very loose definition of the TPUB field ("either label OR publisher"), and
also as a result of the lack of specifics around the TCOP field. Picard
interprets and displays the TPUB field as the name of the label, whereas
MP3Tag (and other tagging apps) display it as "Publisher".
These differences will have a significant impact on the enforcing of
copyright and the payment of royalties to artists, labels and publishers,
specifically as relates to the reporting of usage to performing rights
(and other) societies. For example, when an MP3 is submitted to an
internet radio station that decides to use the included metadata to report
to Soundexchange (the organization that collects money on behalf of
featured performers), the label information is used. If the name of the
publisher is used, there is a risk that the label will not see these
royalties. There needs to be a separate field for the label name.
A distinction needs to be made between the sound recording copyright owner
(could be the same as the label but in case the content is licensed, that
will not be
the case), and the copyright in the composition (the publisher), and
perhaps an additional field is necessary, as well as a clearer description
of what these fields should contain. Although the description in the spec
as relates to the TCOP field would seem to suggest that the name of the
sound recording copyright owner is included in this field, it is not
clearly defined and may be misunderstood by developers. Another source of
confusion is that it is not clear whether the application should prefix
the copyright field with the (C) symbol when displaying the information,
or the person tagging should include the (C) symbol. It is also unclear
whether the year should be included in the field itself when the recording
is tagged, or this field will be prefixed with the data in the 'year'
field when the metadata is displayed, or it will be displayed in the field
heading in the app.
As relates to the TPUB field, the label may be the same as the publisher,
but typically they are different. As we see broader adoption of the
standard and use of the metadata by the music industry, these are issues
that should be dealt with now.
Let me know if there is anything else you need, and if there are any
upcoming meetings where this issue might be discussed.
Looking forward to hearing from you.
Best regards,
Steven
Steven Saffer B.E.Sc (EE), MBA
President
Abbeywood Records
t: [phone]
f: [phone]
c: [phone]
http://abbeywoodrecords.com