ASID Specification(Audio Software Information Delivery)

Version 1.0

July 19, 2001

IFPI
Recording Industry Association of America (RIAA)
Recording Industry Association of Japan (RIAJ)ASID Specification

Version 1.0

Contents
1.

Introduction ..................................................................................................................................................42.

Scope ............................................................................................................................................................53.

Normative References .................................................................................................................................54.

Terms and Definitions .................................................................................................................................6

5.

Structure of ASID .........................................................................................................................................7

6.

ASID Baseline Format .................................................................................................................................8
6.1

ASID Header ID .....................................................................................................................................8

6.2

ASID Format ID .....................................................................................................................................8

6.3

Content Usage Information .................................................................................................................9

6.4

UPC/EAN and ISRC...............................................................................................................................97.

Extended Information Format (TBD)........................................................................................................12

8.

Dynamic Structure Concept (TBD)...........................................................................................................12

9.

Technical Recommendations ...................................................................................................................12
9.1

Transmission ......................................................................................................................................12

9.2

Protection of Software Information ..................................................................................................13

Appendix A(NORMATIVE) ...........................................................................................................................14

Specification of the ASID Adaptation Layer to the IEEE1394 Audio and Music Data Transmission
Protocol..............................................................................................................................................................14
A.1

Scope ...................................................................................................................................................14

A.2

Normative References........................................................................................................................14

A.3

Terms and Definitions .......................................................................................................................14

A.4
Adaptation to the A/M Protocol........................................................................................................14A.4.1
AM824 LABEL .........................................................................................................................14
A.4.2
SUBLABEL ..............................................................................................................................15
A.4.3
Elements of the Baseline Information ..................................................................................15
A.4.4
Transmission...........................................................................................................................17

Annex A

(informative).................................................................................................................................19

Detailed Descriptions .......................................................................................................................................19
INA.1

Rationale for the ASID Proposal ................................................................................................19© 2001 IFPI, RIAA and RIAJ – All rights reserved

2

ASID Specification

Version 1.0

INA.2

Content Usage Information ........................................................................................................20

INA.3

Extended Information Format ....................................................................................................21

INA.4

Protection of Software Information ...........................................................................................21

INA.5

Particular Rules for Implementing ASID ...................................................................................22

INA.6

Dynamic Structure Concept .......................................................................................................22

Annex B(informative).................................................................................................................................23

Example of a Payload Structure for ASID.......................................................................................................23
INB.1

ASID Information Header (clear text).........................................................................................23

INB.2

ASID Information Block (encrypted)..........................................................................................23© 2001 IFPI, RIAA and RIAJ – All rights reserved

3

ASID Specification

1.

Version 1.0

Introduction

This document describes a structure of Audio Software Information Delivery (ASID) and aformat of data elements of Software Information stored and delivered on supporting media
and transmission protocols. ASID is a concept developed by the worldwide recording
industry1 to ensure that a wide variety of Software Information is transported in association
with any audio content regardless of its distribution channels, supporting applications ortransmission protocols. ASID specifies a standard format for Software Information provided
by content owners for the use of their audio content, while keeping extensibility of the format
in accordance with the future needs of parties concerned and consumers.
ASID is capable of providing benefits to consumers as well as content owners. Bytransporting an extensible set of value-added information, ASID will expand experiences ofconsumers who want to have access to quality music. While ensuring them doing so, ASID
will provide owners of audio content with an environment that enables them to accurately
manage and effectively protect Intellectual Property (IP) Rights involved in their content.
This document was produced by efforts made within the worldwide recording industry,
therefore, ASID is considered as a recording industry standard at this present stage.
However, by gaining an inter-industry consensus at some appropriate body, the worldwide
recording industry strongly desires to get it standardized internationally to ensure that all
consumer audio devices and applications can successfully deliver and interpret Software
Information.

1

Three organizations; IFPI, RIAA and RIAJ represent the worldwide recording industry.
© 2001 IFPI, RIAA and RIAJ – All rights reserved

4ASID Specification

2.

Version 1.0

ScopeThis document describes a structure of ASID and a format of data elements of Software
Information that is carried on distribution media and transmitted across interfaces/buses bycertain protocols.
On the other hand, ASID does not specify any implementation that should be individuallyspecified by each interest group2 so that they can accommodate transportation of Software
Information on their platforms. Such specific implementation may involve, for examples,
specific technologies for the transportation of Software Information (e.g. capsulation,watermarking) and particular rules for implementing ASID (e.g. which data element is
mandatory or optional for transportation).
However, to maintain high level compliance with the purpose of ASID, this document
addresses technical recommendations widely applicable to any applications andtransmission protocols implementing ASID. Appendixes of this document also provide
normative adaptation to specific applications or transmission protocols respectively. On theother hand, annexes of this document provide useful information as well as possible
examples for implementation, as informative part.
ASID is intended to provide information applicable only to pure audio content, and not
applicable to audio-visual content such as motion pictures. However, by further
consideration, the scope of ASID could be extended to cover music video content, such asmusic clips, which is a sort of audio-visual content. At the time of consideration, it isrecommended that the scope of music video content that ASID covers should comply withthat of ISRC defined in the ISO 3901 document.

3.

Normative References

The following normative documents contain provisions which, through reference in this text,
constitute provisions of this document. For dated references, subsequent amendments to,or revisions of, any of these publications do not apply. However, parties to agreements
based on this document are encouraged to investigate the possibility of applying the mostrecent editions of the normative documents indicated below. For updated references, thelatest edition of the normative documents referred to apply.
IEC 60908: 1999, Audio recording – Compact disc digital audio system
IEC 60958-1: 1999, Digital audio interface – Part 1: general
IEC 60958-2 TR: 1994, Digital audio interface – Part 2: Software information delivery mode2

For example, a particular consortium or group of hardware/software application vendors, protocol vendors or content
distributors; or relevant standardizing body.
© 2001 IFPI, RIAA and RIAJ – All rights reserved

5ASID Specification

Version 1.0

IEC 60958-3: 1999, Digital audio interface – Part 3: Consumer applications
IEC 61119-6: 1992, Digital audio tape cassette system (DAT) – Part 6: Serial Copy
Management System
ISO 3901 FDIS: 2001, Information and documentation – International Standard Recording
Code (ISRC)
SDMI Portable Device Specification Part 1, Version 1.0: 1999

4.

Terms and Definitions

For the purpose of this document, the following terms and definitions apply.
[Term][Definition](In alphabetical order)

ASID

Audio Software Information Delivery

Baseline Information

A minimum set of Software Information determined by the ASID
Baseline Format, which shall be associated with audio content inany event.

Extended Information

A set of extensive Software Information other than the Baseline
Information.

Software Information

A set of content-associated information defined by ASID for
identification, description and other purposes related to the use ofsound recordings (, which forms part of metadata). It consists ofBaseline Information and Extended Information.

© 2001 IFPI, RIAA and RIAJ – All rights reserved

6

ASID Specification

5.

Version 1.0

Structure of ASID

ASID Specification

Individual
Implementation

This clause defines the structure of ASID illustrated by the Fig. 1 below.

Interfaces/buses
1394

958
USB

Media
DVDA

EMD

SACD

Implementer’s
Rules

Extended Info Format
RecordingIndustry
Extended

Rightsmngmt
societies

Other
metadata
Initiatives

ASID Baseline Format
Set of Baseline Information

Detailed
Descriptions(Including
Implementation
examples)Fig. 1: Structure of ASID
The ASID Specification (this document) defines a hierarchy in the structure of ASID and it
comprises two layers of data formats, one is the ASID Baseline Format and another is the
Extended Information Format.
The ASID Baseline Format defines a definitive set of the Baseline Information that is
minimum elements which all media and interfaces/buses implementing ASID shall transport
in any event. Data elements of the Baseline Information shall be transmitted in fixed length
fields.
The Extended Information Format defines a set of extensive Software Information, excluding
the Baseline Information, having variable length fields that should be transported as well in
association with the audio content. This Format allows extension in accordance with theneeds of parties concerned and will be revised upon a consensus among them. This Format
may involve a variety of data elements that not only the recording industry but also otherparties concerned or other metadata initiatives recommend to transport in association withaudio content.
On the other hand, implementation on each medium or interface/bus is out of the scope of
ASID and should be individually defined by each interest group. Such implementation may
involve, for example, bit mapping on a carriage, payload structure and technological means
to associate Software Information with audio content. A means to implement the technicalrecommendations, addressed in the clause 9 of this document, and particular rules for
implementing ASID should also be individually defined. To facilitate implementation by eachinterest group, possible examples for implementation (e.g. payload structure) are provided
in informative annexes of this document.

© 2001 IFPI, RIAA and RIAJ – All rights reserved

7

ASID Specification

6.

Version 1.0

ASID Baseline Format

This clause specifies a format of the Baseline Information that all media and interfaces/
buses implementing ASID are required to transport on specified fixed-length fields.
All of the reserved bits indicated in this clause are set at 0b unless further defined.
6.1

ASID Header ID

The ASID Header ID identifies that the following table is the beginning of the Baseline
Information. This table may be necessary to identify and signify the information field
preceding audio data in the case that the Baseline Information is transmitted in part of alengthy header field of a data packet.
This ASID Header ID is not required to store on media and allowed to generate on devices
as required in transmission.
The ASID Header ID shall consist of the following four (4) bytes of information encodedusing the ASCII (American Standard Code for Information Interchange) format:
bit 7

bit 6

bit 5

bit 4

Byte 0:
bit 7

bit 6

bit 5

bit 4

Byte 1:

bit 2

bit 1

bit 0

bit 3

bit 2

bit 1

bit 0

bit 2

bit 1

bit 0

bit 2

bit 1

bit 0

‘S’=53h
bit 7

bit 6

bit 5

bit 4

Byte 2:

bit 3‘I’=49h
bit 7

bit 6

bit 5

Byte 3:

6.2

bit 3

‘A’=41h

bit 4

bit 3

‘D’=44h

ASID Format ID

The ASID Format ID identifies the structure of Software Information. In the event the
Extended Information is transported on a medium or an interface/bus, an assigned numberof the ASID Format ID corresponding to the given set of the Extended Information shall betransported as part of the Baseline Information. The details of this information are to be
defined in the clause 8 of this document.
The ASID Format ID shall consist of one (1) byte of information occupying six (6) binary bits,
the bit 0 through the bit5 representing numbers 0 through 63. The remaining two bits (the bit
6 and the bit 7) are reserved for the future use.
In the event only the Baseline Information is transported on a medium or an interface/bus,
the ASID Format ID shall be set at 00h. The other states will be reserved until further defined.
© 2001 IFPI, RIAA and RIAJ – All rights reserved

8ASID Specification

Version 1.0

bit 7

Byte 0:

bit 6

ASID Format ID:
00h
Other states

6.3

bit 5

bit 4

Reserved

bit 3

bit 2

bit 1

bit 0

ASID Format ID

Only the Baseline Information is transported.
Reserved

Content Usage Information

The purpose of this field is to reserve a certain amount of bit space commonly usable forcontent protection schemes to transport their usage rules information. At the moment, thisdocument does not identify any specific usage rules information transported on this field.
It is still under consideration that delivery of a bit for assertion of copyright is useful. The
figure below contains assignment for this bit, however, this bit shall not be made effective
and shall be set at 0b until practical usage for this bit is further defined in a later version ofthis document or a separate documentation.
The number of bytes capable of reserving for this information will vary among media andinterfaces/buses. However, it is recommended that each interest group reserve at least
eight (8) bytes of information space as shown below.
bit 7

bit 6

bit 5

Byte 0:

bit 4

bit 3

bit 2

bit 1

bit 0

Reserved
Copyright
Assertion (TBD)
bit 7

bit 6

bit 5

Byte 1 - 7:

6.4

bit 4

bit 3

bit 2

bit 1

bit 0

Reserved

UPC/EAN and ISRC

UPC3 (Universal Product Code) and EAN4 (European Article Number) are product identifiers,
thirteen (13) digits in length, encoded using a Binary Coded Decimal (BCD) format.
ISRC5 (International Standard Recording Code) is a coding scheme standardized by ISO touniquely identify a sound recording (sometimes a music video recording as well). It consistsof alphanumeric 12 characters, using Arabic numerals 0-9 and letters of the Roman
alphabet.

3

http://www.uc-council.org/
http://www.ean-int.org/
5
http:///www.ifpi.org/technology/isrc_what.html
4© 2001 IFPI, RIAA and RIAJ – All rights reserved

9ASID Specification

Version 1.0

To facilitate identification of the validity of these two codes, four (4) bits of Validity
Information shall precede the information field for them.
This field shall consist of thirty-two (32) bytes of information occupying sixteen (16) bytes as
defined below. The remaining sixteen (16) bytes are reserved for the future extension of the
ISRC format and other purposes.
bit 7

Byte 0:
bit 7

Byte 1:
bit 7

bit 7

bit 7

bit 7

bit 7

bit 6

bit 5

bit 6

bit 5

bit 6

bit 5

bit 6

bit 5

bit 6

bit 5

bit 6

bit 5

bit 6

bit 4

bit 6

bit 4

bit 3

bit 6

bit 4

bit 6

bit 4

bit 6

bit 4

bit 3

bit 6

bit 2

bit 1

bit 0

bit 3

bit 2

bit 1

bit 0

bit 3

bit 2

bit 1

bit 0

bit 3

bit 2

bit 1

bit 0

bit 3

bit 2

bit 1

bit 0

UPC/EAN #13
bit 4

bit 3

bit 2

bit 1

bit 0

bit 1

bit 0

bit 1

bit 0

bit 1

bit 0

bit 1

bit 0

bit 1

bit 0

Country Code (ISRC #1)
bit 5

bit 4

bit 3

bit 2

Country Code (ISRC #2)
bit 5

bit 4

bit 3

bit 2

Registrant Code (ISRC #3)
bit 5

bit 4

bit 3

bit 2

Registrant Code (ISRC #4)
bit 5

bit 4

bit 3

bit 2

Registrant Code (ISRC #5)
bit 5

bit 4

Year of Reference (ISRC #6)
bit 7

bit 0

UPC/EAN #11

Reserved
bit 7

bit 1

UPC/EAN #9

Reserved
bit 7

bit 2

UPC/EAN #7

Reserved
bit 7

bit 0

UPC/EAN #5

Reserved
bit 7

bit 1

UPC/EAN #3

Reserved
bit 7

Byte 13:

bit 4

UPC/EAN #12
bit 7

Byte 12:bit 5

UPC/EAN #10

Byte 6:

Byte 11:

bit 6

bit 2

UPC/EAN #1

UPC/EAN #8

Byte 5:

Byte 10:

bit 3

UPC/EAN #6

Byte 4:

Byte 9:bit 4

UPC/EAN #4

Byte 3:

Byte 8:

bit 5

UPC/EAN #2

Byte 2:Byte 7:

bit 6

Validity Information

bit 5

bit 4

Designation Code (ISRC #8)© 2001 IFPI, RIAA and RIAJ – All rights reserved

bit 3

bit 2

Year of Reference (ISRC #7)
bit 3

bit 2

bit 1

bit 0

Designation Code (ISRC #9)

10

ASID Specification

Version 1.0

bit 7

Byte 14:

bit 6

bit 5

bit 4

bit 3

Designation Code (ISRC #10)
bit 7

Byte 15:

bit 6

bit 5

bit 4

bit 3

Designation Code (ISRC #12)
bit 7

bit 6

bit 5

bit 4

bit 3

Reserved

:
:

:
:
bit 7

bit 6

bit 5

Validity Information:
0000b
1000b
0100b
1100b
Other states

bit 1

bit 0

bit 2

bit 1

bit 0

Reserved

Byte 16:

bit 4

Byte 31:

bit 2

Designation Code (ISRC #11)

bit 3

bit 2

bit 1

bit 0

bit 2

bit 1

bit 0

Reserved

All data invalid
UPC/EAN valid
ISRC valid
Both UPC/EAN and ISRC valid
reserved

ISRC
ISRC #1 - #2
ISRC #3 - #5
ISRC #6 - #7
ISRC #8 - #12

Country code
Registrant code
Year of reference
Designation code

UPC/EAN #1 through #13 and ISRC #6 through #12 shall be encoded using the BCD format.
ISRC #1 through #5 shall be encoded as shown in the Table 1 below.
Character01

Code000000000001

2
3
4
5
6
7
8
9
A
B

000010000011000100000101000110000111001000001001010001
010010

Table 1: Character Code (binary) for ISRC
Character
Code
Character
C
010011O
D
010100
P
E
F
G
H
I
J
K
L
M
N

© 2001 IFPI, RIAA and RIAJ – All rights reserved

010101010110010111011000011001011010011011011100011101011110

Q
R
S
T
U
V
W
X
Y
Z

Code
011111
100000100001100010100011100100100101
10011010011110100010100110101011

ASID Specification

7.

Version 1.0

Extended Information Format (TBD)

This clause is prepared to describe the Extended Information Format. Data elements
included in this format are to be composed of variable length fields and the details are to be
defined at a later date when the recording industry reaches a more solid understanding of
their requirements on metadata. Since this format will not be populated until such time, theworldwide recording industry recommends that potential implementers of ASID reserveadequate and effective spaces for transporting the Extended Information on their media andprotocols without defining its format.
Even after the initial data elements are defined for this format, it retains the future
extensibility in accordance with the needs of parties concerned and consumers.
Each interest group implementing ASID may tailor the configuration of data elements
defined in this format as far as they comply with the Dynamic Structure Concept describedin the clause 8 of this document.

8.

Dynamic Structure Concept (TBD)

This clause is prepared to define a common mechanism that allows particular interest
groups to individually tailor the configuration of data elements defined in the Extended
Information Format. The mechanism for this purpose is tentatively called the Dynamic
Structure Concept. The details of this mechanism are to be determined by further
consideration.

9.

Technical Recommendations

The ASID Specification does not identify any specific technology (e.g. encryption) for thetransportation of Software Information, which should be individually determined by eachinterest group implementing ASID, however, it addresses technical recommendations for
implementation. The recommendations aim to ensure that Software Information, retaining its
integrity, is successfully delivered to consumer devices and applications. It is recommended
that each interest group implement ASID with technologies that satisfy therecommendations in this clause.
9.1

Transmission

It is recommended that a certain set of Software Information should be transmitted
repeatedly during streaming of a sound track to ensure that they are successfully delivered
to a receiver whenever it starts receiving of the stream. The certain set should involve thefull set of the Baseline Information and may involve some selected elements of the
Extended Information. The recommended transmission interval is real time period of
approximately 0.5 second of the stream unless otherwise specified in normative appendixes.

© 2001 IFPI, RIAA and RIAJ – All rights reserved

12ASID Specification

Version 1.0

It is possible to transmit Software Information by a variety of technological means, but it isrecommended that the Baseline Information should be transmitted on a header of a data
packet as a minimum adoption.
9.2

Protection of Software Information

It is recommended that Software Information should be transported in a protected manner tomaintain its integrity. In case that Software Information is transmitted in clear text, eachinterest group should provide a receiver with a means to verify the integrity of Software
Information. The delivery of the Baseline Information on a header is a possible example forthe clear-text transmission and an example of payload structure to achieve this verification
is provided in the informative Annex B. It is recommended that each device or application
implementing ASID should not use the delivered Software Information if the integrity of theinformation cannot be verified.
Whether Software Information needs protection or not depends on the type of each data
element and what purpose it is used for. Therefore, it is recommended that interest groups
implementing ASID should build a system on which content owners may selectively
determine in which form they provide each data element;-

In protected form;
In clear-text form or;
In both the forms.

© 2001 IFPI, RIAA and RIAJ – All rights reserved

13

ASID Specification

Version 1.0

Appendix A (NORMATIVE)
Specification of the ASID Adaptation Layer to the IEEE1394 Audio and Music Data
Transmission Protocol
A.1

Scope

This appendix defines the Adaptation Layer applied to the IEEE 1394 Audio and Music Data
Transmission Protocol (hereafter the A/M Protocol). Devices and modules employing the1394 A/M Protocol are able to implement ASID by adopting corresponding specifications
issued by the 1394 Trade Association (1394TA6), in conjunction with this appendix.
At the moment, the ASID Specification has only defined the ASID Baseline Format and has
not defined any further format including the Extended Information Format. Therefore, thisappendix only defines the Adaptation Layer of the ASID Baseline Format. That of the
Extended Information Format will be specified at a later date when the worldwide recording
industry defines its format.

A.2

Normative References

In addition to the documents referred in the clause 3, the following normative documents arereferences to this appendix. For updated references, the latest edition of the normative
documents referred to apply.
1394TA Document 2001003 – Audio and Music Data Transmission Protocol 2.0
A.3

Terms and Definitions

Terms and definitions in this appendix follow the clause 4, except those related to the A/M
Protocol that should be referred to corresponding 1394TA specifications.
A.4

Adaptation to the A/M Protocol

This clause defines adaptation to the IEEE 1394 A/M Protocol for delivering the Baseline
Information.

A.4.1

6

AM824 LABEL

http://www.1394ta.org/© 2001 IFPI, RIAA and RIAJ – All rights reserved

14

ASID Specification

Version 1.0

As ASID is intended to be a scheme applicable to any audio content, the Baseline
Information shall be transmitted in such a manner that all devices and modules can havecommon access to it regardless of their types. To achieve such purpose of ASID, theBaseline Information shall be transported across the entity for the Common Ancillary Dataassigned by the AM824 LABEL.
The A/M Protocol 2.0 specification has assigned a unique AM824 LABEL with the value C0h
to ASID, within the range for the Common Ancillary Data.

A.4.2

SUBLABEL

A data payload for delivering the Baseline Information shall incorporate a SUBLABEL of 8bit length in its structure, as defined in the A/M Protocol 2.0 specification.
The Table 1 below defines a unique range of SUBLABELs for each applicable element of
the Baseline Information.
SUBLABEL
00h - 0Fh

Baseline
Format10h - 1Fh
The other states
Table 1.

A.4.3

Definitions
UPC/EAN and ISRC
Content Usage Information
Reserved

SUBLABEL Definition

Elements of the Baseline Information

This subclause defines adaptation of each data element of the Baseline Information.

A.4.3.1

ASID Header ID

The purpose of the Header ID is to identify the beginning of the ASID Baseline Information
in some lengthy header field. However, on the A/M Protocol, the allocation of a uniqueAM824 LABEL for ASID can fully meet the purpose of the Header ID and it can be replacedby this allocation. Therefore, the A/M Protocol does not need to implement the Header ID.

A.4.3.2

ASID Format ID

The purpose of the Format ID is to identify the configuration of transported data elements ofthe Extended Information. However, the Extended Information Format has not been defined
yet and the Format ID is currently fixed at 00h, meaning that the transported information
contains only the Baseline Information. Therefore, it is adequate at the moment if the
SUBLABELs can identify the Baseline Information being delivered. Therefore, the A/M
Protocol does not need to implement the Format ID at the moment.

© 2001 IFPI, RIAA and RIAJ – All rights reserved

15

ASID Specification

Version 1.0

When the Extended Information Format is defined, a means to deliver the ASID Format ID is
to be added to this appendix.

A.4.3.3

Content Usage Information

Content Usage Information shall be delivered on the Common Ancillary Data as defined
below.
SUBLABEL

bit 15

bit 0

10h:

Reserved
Copyright
Assertion (TBD)
bit 15bit 0

11h – 1Fh:

Reserved

A.4.3.4

UPC/EAN and ISRC

UPC/EAN and ISRC information shall be transmitted in such a way that modules caninterpret the information in a compliant manner as defined in the subclause 6.4.
In principle, this information shall be delivered on the Common Ancillary Data as defined
below, except the following cases:z

In the case that the whole data stream sent out from a transmitter is encrypted by aspecific bus-protection scheme and the transmitter has technological difficulties insending the Common Ancillary Data, UPC/EAN and ISRC information may
alternatively be delivered on the Application-Specific Ancillary Data by a proprietarymeans required by the scheme.

SUBLABEL bit 15
00h:

bit 8

Byte 0 (UPC/EAN and ISRC)

SUBLABEL bit 15
01h:

bit 8

03h:

bit 7

bit 8

bit 7

bit 0

Byte 7 (UPC/EAN and ISRC)
bit 8

bit 7

Byte 8 (UPC/EAN and ISRC)© 2001 IFPI, RIAA and RIAJ – All rights reserved

bit 0

Byte 5 (UPC/EAN and ISRC)

Byte 6 (UPC/EAN and ISRC)

SUBLABEL bit 15

bit 0

Byte 3 (UPC/EAN and ISRC)
bit 8

SUBLABEL bit 15
04h:

bit 7

Byte 4 (UPC/EAN and ISRC)

SUBLABEL bit 15

bit 0

Byte 1 (UPC/EAN and ISRC)

Byte 2 (UPC/EAN and ISRC)

SUBLABEL bit 15
02h:

bit 7

bit 0

Byte 9 (UPC/EAN and ISRC)
bit 8

bit 7

bit 0

16

ASID Specification

05h:

Version 1.0

Byte 10 (UPC/EAN and ISRC)

SUBLABEL bit 15
06h:

bit 8

bit 7

Byte 12 (UPC/EAN and ISRC)

SUBLABEL bit 15
07h:

Byte 11 (UPC/EAN and ISRC)

bit 8

Byte 14 (UPC/EAN and ISRC)

bit 0

Byte 13 (UPC/EAN and ISRC)
bit 7

bit 0

Byte 15 (UPC/EAN and ISRC)

SUBLABEL bit 15

bit 0

08h – 0Fh:

Reserved (follows the same order as the above)

In case that a content distribution medium fully implements the reserved fields (the Byte 16
through the Byte 31 as defined in the subclause 6.4), devices and modules shall transmit allof the data fields (SUBLABEL 00h through 0Fh) and receive all of them to maintain futurecompliance with expected revisions of the ISRC syntax.
The Byte 0 field carries the Validity Information as defined in the subclause 6.4. In the casethat the Validity Information on the media indicates the state 0000b or no corresponding
information is conveyed on the media, the playing devices may not transmit this element
fulfilled with zero bits.

A.4.4

Transmission

A.4.4.1

Update of Information

The Baseline Information transmitted shall change only in accordance with the updates in its
information source. Devices and modules shall be designed in such a way that payloads
transmitted from them appropriately represent these updates in the source.
In the event that the information source is updated, transmitted payloads shall represent
these updates at an earliest transmission event.

A.4.4.2

Timing Issues

The full set of the Baseline Information shall be repeatedly transmitted in approximately
every 0.5 seconds during streaming of a sound track.
There are cases that a distribution medium repeatedly and simultaneously records the full
information set along with the content stream. The playing devices and modules may
transmit such recorded information as it is so long as the interval of the recorded information
sets reasonably satisfies the above definition and complies with the adaptation set forth in
the subclause A.4.3.3 and A.4.3.4.
Implementers of ASID may choose either of the following ways to execute transmission of
events for the Baseline Information:© 2001 IFPI, RIAA and RIAJ – All rights reserved

17

ASID Specification

Version 1.0-

Transmit the full set of the information in one event (one block)-

Divide the full set of the information into units and transmit them at random timings
within the transmission period required above

A.4.4.3

A Guide on Transmission of Clear-Text Information

This appendix has defined the format of the Baseline Information transmitted as part of theCommon Ancillary Data. To enable access from any device and module in a common
manner, it is considered appropriate that, in general, the Baseline Information on the
Common Ancillary Data is delivered in clear text with providing a means to verify its integrity.
However, some bus-protection schemes for 1394 (e.g. 5CDTCP7) are designed to keep thewhole data stream (i.e. audio content stream including Ancillary Data) encrypted. Then, theCommon Ancillary Data will be encrypted as well, and no clear-text Baseline Information isavailable on such an encrypted bus.
Even if the case, there might be some possible means to transmit the clear-text Baseline
Information along with the encrypted stream on the same bus. However, serious concerns
from the security aspect have been raised against such design because sending clear-text
information, that is duplicated in encrypted portion of the data stream, may potentiallyjeopardize the security of the bus protection. A malicious attacker could destroy the securityof the bus protection by some comparative analysis method.
Therefore, the security consideration shall be prioritized if an implementer of ASID has anintention to design their devices and modules to transmit clear-text information in such way.

7

http://www.dtcp.com/© 2001 IFPI, RIAA and RIAJ – All rights reserved

18

ASID Specification

Annex A

Version 1.0(informative)

Detailed Descriptions
INA.1 Rationale for the ASID Proposal
The recent innovation of technologies for music distribution, especially EMD (Electronic
Music Distribution), has brought excellent experiences to consumers by offering easy
access to quality music. Consumers have become able to have access to a wide variety ofaudio contents via network media (e.g. Internet) and broadcast media (e.g. DAB, cables) as
well as packaged media existing (e.g. CD) and emerging (e.g. DVD-Audio, SACD). Easy
access to these media has been being offered by not only consumer electronics devices but
also personal computers, set top boxes, portable flash-memory music players and, in thenear future, portable phones.
While plenty of technology vendors are trying to develop infrastructures to deliver audio
content, the recording industry is concerned about whether they can ensure that an
adequate set of information related to the content (i.e. metadata) is successfully transported
throughout such infrastructures. A content delivery chain essentially consists of content
creation and production, a distribution channel (medium), end-point consumer
devices/applications and interfaces/buses (protocols) connecting each other. The recording
industry believes that some standard set of copyright information and other information
related to the use of the content must be successfully transported throughout all content
delivery chains in association with any audio content.
However, unfortunately, there has been no inter-industry scheme that has alreadysucceeded in the standardization of a format for metadata because it takes a longer time togain a consensus on the format among parties concerned. In the meantime, there are aconsiderable number of media and protocols that have been, or are being, designed without
consideration of transporting such information. The recording industry is greatly concerned
about that because, even though we desire to transport such information once its format isfixed, we may face a problem that no adequate and effective space is left on them for thetransportation.
Consequently, the worldwide recording industry decided to start development of a format for
metadata (part of which is the ASID Specification) in a short term by inner-industry efforts.
However, we are still in the process of defining data elements and our work needs more andmore discussion even within the industry.
Therefore, we have decided that we would first define a limited set of Software Information(the ASID Baseline Format) and ask potential implementers of ASID to first implement it on
their media and devices. Then we would encourage them to reserve adequate and effective
spaces for transporting a broader range of Software Information (i.e. the Extended
Information) coming later. The ASID Baseline Format consists of minimum essential data
elements of which transportation should be achieved at an early date. Once the Extended
Information Format is finalized by inner-industry discussion, we will try to gain an inter-© 2001 IFPI, RIAA and RIAJ – All rights reserved

19

ASID Specification

Version 1.0

industry consensus on the implementation of ASID at some appropriate body and get the
specification standardized internationally.
INA.2 Content Usage Information
Only a content owner has the right to determine usage rules to govern copy, playback
and/or distribution of his/her audio content on consumer devices and applications. To makethis control effective, this field for Content Usage Information is prepared to transport avariety of data elements providing usage rules, in association with the audio content.
The most popular copy control scheme for audio content is the legacy SCMS (Serial Copy
Management System), and it has been widely adopted on consumer digital audio recording
devices, such as MiniDisc, CD-R. On the IEC 60958 interfaces, a control signal to govern
the SCMS functionality is conveyed by two–bit information between players and recorders toprevent consumers from making any second-generation copy (a copy of a copy) whileallowing them to make multiple first-generation copies (copies of the original). Such control
signal could be considered as a sort of Content Usage Information.
However, such information recently developed is normally subject to particular content
protection schemes that have been proprietarily developed by specific technology vendors,
and the details of the information dealing will not be disclosed for those who have notacquired a license from the vendors. Furthermore, it is up to individual negotiation among
parties concerned to determine what protection scheme they exclusively adopt on a specificmedium and devices.
Therefore, this specification does not define any data element subject to a specific content
protection scheme, except one bit of information asserting the ownership of copyright.
Parties concerned should agree upon the adoption of a content protection scheme on a
specific media, and this agreement is obviously out of the scope of ASID.
The following is nothing other than examples possible to consider as Content Usage
Information:z

Copy control information

Information could be transported on this field to effectively govern the capability of making
copies of the audio content on compliant recorders, in accordance with the discretion of thecontent owner.
z

Check In/Check Out

Check In/Check Out is a functionality that enables a content owner to entirely control thenumber of copies made by consumers, defined by the SDMI Portable Device Specification.
Information to govern this functionality could be comprised of two components, the numberof allowed copies and the number of copies completed. The content owner or distributor
assigns the former information, and a functionality processing, updating, and storing thelatter information needs to be devised by a medium.

© 2001 IFPI, RIAA and RIAJ – All rights reserved

20

ASID Specificationz

Version 1.0

Data to Control Valid Period for Playback/Copy

This data would provide a restricted or non-restricted condition when a content owner has
an intention to apply valid-period control for playback and/or copying of the content. This
control could be achieved by transporting information asserting whether valid period isrestricted or not and information of specific time periods determined by the content owner or
distributor.

INA.3 Extended Information Format
The Extended Information Format could consist of, but not limited to, such kind of Software
Information as follows:
z
z
z
z
z

Data for identification of various musical elements (e.g. identification of musical works)
Data for description of the content (e.g. text information)
Data for references (e.g. URL links)
Data for indication of the attributes of the content delivery (e.g. encrypted or not)Data for professional (studio and manufacturing) purposes

INA.4 Protection of Software Information

As described in the normative text, this specification recommends that interest groups
implementing ASID should build a system on which content owners can selectively
determine whether they provide each element of Software Information in protected form ornot. This determination of the content owner depends on the type of each data element andwhat purpose it is used for.
The reason for this recommendation is because ASID will provide not only value-added
information that should be protected from tampering but also instructive and useful
information that should be kept open for any receivers. If the latter one is encrypted and theaccess to it is restricted, the purpose of providing such information will not be accomplished.
For example, as a simple case, a recipient may need to know what the content is before
proceeding with the procedure to purchase it. Therefore, such information should bedelivered in clear-text from.
On the other hand, the value-added information or information that is supposed to provide
incentives for hackers, e.g. copy management information, must be robustly protected frommalicious attacks.
ISRC is an expected example that may be transported in both protected form and clear-text
form. One possible usage of ISRC is to identify a sound track that a recipient wants to haveaccess to. The recipient may retrieve the sound track by a given ISRC. For this purpose,
ISRC should be in clear text. On the other hand, ISRC will be used for monitoring the use ofcontent and collecting a charge from a recipient. ISRC for this purpose will greatly provide© 2001 IFPI, RIAA and RIAJ – All rights reserved

21

ASID Specification

Version 1.0

incentives for hackers to alter or tamper with it. Therefore, the same information as theclear-text ISRC will need to be transported separately in protected form.
In this case, the integrity of the clear-text ISRC could be verified by comparing it with theprotected ISRC.

INA.5 Particular Rules for Implementing ASID
This document does not specify any particular technologies and rules for the implementationof ASID, and these should be determined by each interest group in negotiation with therecording industry. The following is examples of particular rules:-

Which data element is in use, or not in use
Which data element is mandatory, or optional
What is particular functionality in response to specific element, if necessary

INA.6 Dynamic Structure Concept
As the ASID implementation is not confined to a particular transport medium or end-point
consumer device, some mechanism to provide vendor flexibility may need to be adopted inthis document. There may be some cases that several data elements defined in the
Extended Information Format are invalid on a particular distribution medium because of theuniqueness of its business model. To meet unique requirements of particular interest groups,
this document needs to define a common mechanism that allows them to individually tailor
the configuration of data elements defined in the Extended Information Format.
It may be reasonable to consider that the mechanism will require some registration authoritythat approves and manages variations of registered formats. It will also assign a unique
ASID Format ID to an individual format registered. To provide receivers of audio content
with capability to identify the configuration of the Extended Information, an assigned numberof the ASID Format ID corresponding to the given configuration will be delivered as part ofthe Baseline Information.

© 2001 IFPI, RIAA and RIAJ – All rights reserved

22

ASID Specification

Annex B

Version 1.0(informative)

Example of a Payload Structure for ASID
It is possible to transmit Software Information in two separate components – a clear-text“Information Header” and an encrypted “Information Block.” (see Fig. 2 below)

Full Set of Software Information (Clear Text)

Concern = Open for attack before, during, and after transmission
Same Portion as IH

Solution =Clear Text IH

Encrypted IB (Full Set of Software Information)
Decryption
Same Portion as IH

Clear Text IH

Decrypted (Clear Text) IB

Encrypted IH portion is used to verify the integrity of the clear text IH
IH: Selected set of Software Information transported in clear text
IB: Full set of Software Information transported in encrypted form

Fig. 2: Example of a Payload Format to Protect Software Information
INB.1 ASID Information Header (clear text)
The ASID Information Header (IH) could consist of data elements that allow access fromany receivers to let them widely know the basic attributes of the audio content. This field
could be transmitted in a fixed-length header of the audio data packet. Possible examples
for elements transmitted in this field are as follows:-

Full set of Baseline Information
Some appropriate elements involved in the Extended Information Format

INB.2 ASID Information Block (encrypted)
The ASID Information Block (IB) could consist of the whole Software Information (full set of
the Baseline Information and the Extended Information) in an encrypted form, including a© 2001 IFPI, RIAA and RIAJ – All rights reserved

23

ASID Specification

Version 1.0

second instance or copy of the information transmitted on the ASID IH. This information
could be transmitted in a content file as an XML tag, for example.
Inclusion of the second copy of the IH would provide an opportunity to verify the integrity of
the clear-text IH. The receiver is able to identify whether the IH has been tampered or notby comparing it with the corresponding elements included in the protected IB. In case that it
has been determined the IH was tampered or altered, subsequent use of the audio content
should be prohibited as described in the normative text. Possible examples of a logic flow tocontrol content access can be found in the next annex.
The secondary advantage of including the second copy would be an ability to allow theoriginal ASID IH to be removed from active storage of the receiver devices.

© 2001 IFPI, RIAA and RIAJ – All rights reserved

24

ASID Specification

Version 1.0

Copyright © 2001 by IFPI, RIAA and RIAJ,IFPI (Engineering Committee)
54 Regent Street, London W1R 5PJ, UK
TEL: +44 171 878 7900 FAX: +44 171 878 7960

http://www.ifpi.org/

Recording Industry Association of America (Engineering Committee)
1330 Connecticut Ave, NW, Suite 300, Washington DC, 20036, USA
TEL: +1 202 775 0101
FAX: +1 202 775 7253
http://www.riaa.com/
Recording Industry Association of Japan (Engineering Committee)
7-16-3 Ginza, Chuo-ku, Tokyo, Japan 104-0061
TEL +81 3 3541 4414
FAX: +81 3 3541 4815
http://riaj.japan-music.or.jp/
All rights reserved.

© 2001 IFPI, RIAA and RIAJ – All rights reserved25