In This Section
SC-02-02 meeting, San Francisco, 2004-10
Report of the SC-02-02 Working Group on digital input/output interfacing of the SC-02 Subcommittee on Digital Audio held in conjunction with the AES 117th Convention in San Francisco on Tuesday, 2004-10-26The meeting was convened by SC chair R. Caine in place of the WG chair who was unable to attend.
The agenda was accepted as written. The report of the previous meeting in Berlin was accepted (having already been approved on the SC-02-02 reflector), as was the report of the meeting of SC-02-05.
Open ProjetcsAES-R4-R: Review of AES-R4 2002: Guidelines for AES standard for digital audio - Digital input-output interfacing - Transmission of digital audio over asynchronous transfer mode (ATM) networks, AES47
Revision of control structure and SNMP reflecting on AES47 will soon be necessary. New information will be written by 2005 for IEC purposes. This document is really only applicable to AES47, but impinges on other projects.
AES-2id-R: Review of AES-2id-1996 (r2001): AES information document for digital audio engineering - Guidelines for the use of the AES3 interface
There is a great deal of material in a rough PTD and the main point of discussion is the contents and ordering. No objection was made to keeping AES-2id in one document, rather than the three parts proposed for AES3. S. Lyman offered to provide input on non-linear audio and non-audio data for the relevant clause (6.5). Caine asked the whole group to contribute if possible.
AES-3id-R: Review of AES-3id-2001: AES information document for digital audio engineering - Transmission of AES3 formatted data by unbalanced coaxial cable
This will eventually be retired, when its substance is incorporated in AES3 and AES-2id, but might need reaffirmation in the meantime.
AES-10id-R: Review of AES-10id-1995 (r2000): AES information document for digital audio engineering - Engineering guidelines for the multichannel audio digital interface (MADI) AES10
This has now passed to CFC and cannot therefore be discussed.
AES3-R: Review of AES3-2003: AES Recommended practice for digital audio engineering - Serial transmission format for two channel linearly represented digital audio data
Already agreed to split into three parts, audio essence, metadata/subcode and electrical/physical sections. Revision date is actually 2008 not 2005 as agenda suggests. Caine suggested that jitter section should be reduced and much of the existing important data should be preserved in AES-2id or in a new document being planned by C. Travis. There is a problem in that the Travis document would need to increase its scope and Travis may not wish to do that. However, some of the AES3 jitter material includes the effect of transmission jitter on sample timing. Caine suggested addressing Part 3 - electrical and physical - first, thus resolving jitter question and AES-3id revision as soon as possible. Goal PTD (contents only perhaps) May 2005, Target: revision by 2008 (but some parts before that).
AES5-R: Review of AES5-2003: AES recommended practice for professional digital audio - Preferred sampling frequencies for applications employing pulse-code modulation
No action requested or required. Review in 2008.
AES10-R: Review of AES10-2003: AES Recommended Practice for Digital Audio Engineering - Serial Multichannel Audio Digital Interface (MADI)
Revision required in 2008. There are some comments outstanding which may be integrated at that time. S. Harris asked whether silicon components will still be available. Both Caine and M. Page said that programmable logic offered solutions to FDDI transmission.
AES11-R: Review of AES11-1997: AES Recommended Practice for Digital Audio Engineering - Synchronization of digital audio equipment in studio operations
A new annex (B) is offered describing a method of locking many sample rates from a single tone where no video reference is available. The diagram needs some acknowledgement to the originators - ATM Audio Visual Association (ATMAVA), but does not otherwise need copyright clearance. S. Lyman asked whether the timecode offered any advantage in terms of lip-sync but Caine said that the annex only referred to non-video situations. C. Chambers said that a more advanced version was being investigated to lock video and multiple audio rates synchronously.
Agreed to add word 'informative' to title of the annex. J. Schmidt asked whether confusion might arise if an AES11 reference and this scheme used the same coax connection. However, this was not felt to be relevant to this annex which refers specifically to structured wiring.
Some discussion took place on the details of voltage level etc, but while referring to a specific case (and available products) the annex is as general as possible. A correction to the drawingis required (missing line), acknowledgement required and a reference to origins (BBC web URL and IBC2003 paper).
Goal: PWD for amendment of AES11 immediately (Secretariat to progress) proceed to amend AES11-2003, Target 12-2004
AES18-R: Review of AES18-1996 (r2002): AES recommended practice for digital audio engineering - Format for the user data channel of the AES digital audio interface
No action requested or equired. Review in 2007
AES41-R: Review of AES41-2000: AES standard for digital audio - Recoding data set for audio bit-rate reduction
A request for cases of actual implementations has produced no response. However, the document might still be important. This standard must be reviewed during 2005
There was a discussion on procedures for retiring and withdrawing standards, including an enquiry about SMPTE practice. R. Chalmers will discuss retirement with M. Yonge. S Harris objected to withdrawing a published document without good cause, saying that two minutes discussion at each meeting is a small price for keeping it alive, which is important while it is still in use (even if there is no intention to develop it further).
AES47-R: Review of AES47-2002: Digital Audio in asynchronous transfer mode (ATM)
The basic audio content standard (AES47) should not be confused by adding control. Separate documentation will be required, R Caine suggesting a multipart document. AES47 could incorporate any output from AES-X144.
Revision by 2007, but an amendment is expected before then.
Development ProjectsAES-X111: Transmission of a unique identifier on AES3
C. Chambers gave a resume of recent reflector traffic. The basis of this is the significance of the transitory nature of interface traffic versus stored material. Current AES-X111 provision is for any kind of ID (UUID (universal), GUID (general), UMID (SMPTE Unique Material Identifier) etc. Title and minor details need changing. Chambers described the uses of IDs, eg automatic routing, and prohibition of certain routes. Some signaling has been provided for in a UUID (an audio-change boundary flag in octet 0). S Harris asked about block structure of a AES-X111 user signal. Channel status indication of metadata implies block structure. Sec.to format PWD. A short discussion led to a preference for the word "Octet" rather than "byte".
Goal: Sec formatted PWD Dec 2004. Target Standard 2005
AES-X119: Standard Connector for AES3 interfaces (XLD)
M Yonge summarized the current status. The task group have not agreed on the content of the questionnaire. Thus secretariat has not been able to progress the project. R Caine focused the discussion on the issue of the questionnaire, reminding the group that their remit is only the inclusion of any XLD (non-compatible) part in AES3, the standardization and inclusion of such a part in AES42 being outside of SC-02-02. W Bachman expressed the urgency of moving on if the project is to make any sense commercially. It is not viable to add a compatible variant of every type of chassis-mount part, known informally as XLC (eight more parts at least). He described a new solution to the engineering problems of manufacturing the "compatible" versions, comprising two barrel-type adapters which can only be fitted or removed from chassis-mounted XLRs by means of a tool, thereby converting them from original XLR parts to XLD parts. This has the advantage that legacy equipment can also be converted. The conversion of cable-mounted connectors is to be achieved by means of exchangeable (tool-only) outer barrels (as previously described). J Schmidt emphasized the need for the connector in order to prevent damage from phantom power sources, rather than the simple incompatibility of analogue and digital signals. W Bachman emphasized that the fixed-digital part would still be available if this path is followed.
The chair brought the discussion back to the questionnaire. The present version is not likely to be agreed, but a much simpler one might be. It was unanimously agreed that the questionnaire has to be accompanied by the tutorial. A long discussion followed on the nature of the questionnaire and consensus on it. The possibility of a completely different connector was raised again, and dismissed as not relevant to the current discussion. S Harris said that this was raised at the earliest stages of AES42 and abandoned as too expensive in the small volumes expected.
The discussion turned to setting only two simple questions. W Bachman suggested: Q1: If a new, incompatible XLR variant were available for digital audio (known as XLD) would you use it? and Q2: If there were a compatible version would you use that?
The WG could pass the job back to the TG, but it was felt that this would extend the timing and probably solve nothing. The WG is able to make small adjustments and go ahead, ie ask for WG approval of a PWD. W Bachman suggested only a small change to the arrangement of drawings to clarify the present options. Also, the questions should be on the front page, leaving the tutorial for explanation of the existence of the questions. This will be put on the web, and also have headlines on AES e-news. The exact wording of the questions was written down by M Yonge:
Q1: Would you use the XLD if it were available?,
Q2: If so, would you also need the XLC (compatible) version?
Also a a note at the bottom should be added saying:-
XLD :- An XLR style connector which does not mate with an XLR and is designed for digital audio.
XLC:- A connector which will mate with either XLR or XLD.
This revised questionnaire is hereby proposed to the whole WG by way of posting this report to the SC-02-02 reflector
Goal PWD asap, Target Report Nov/Dec 2004
AES-X121: Synchronisation of digital audio over wide areas
As last time. To be raised again when J. Grant can pay it more attention. PTD May 2005 Target Report
AES-X139: Liaison with EBU P/AGA
EBU have decided to continue their Tech 3250 document and will republish it essentially identical to with AES3. R Caine suggested that the restructured AES3 referred to above might move towards EBU requirements, eg in respect of the mandate of I/O transformers. R Chalmers pointed out that some other projects, eg AES-X111 impinge on this.
AES-X140: High Resolution Multichannel Audio Interconnection (HRMAI)
M Page reported. This is now at PWD and is ready to move forward. A new PWD with minor corrections will be prepared by Secretariat, offered to the reflector and move to PCFC. An Ethernet type is required, costing real money, but will apply to any AES defined protocol. Page explained some of the reasons for needing such an Ethernet type.
PWD immediate, PCFC Dec2004, Target Standard 2005
AES-X143: Transmission of asynchronous transfer mode (ATM) over an Ethernet physical layer
C Chambers reported. This proposed standard allows AES47 to be transported over Ethernet hardware, such as PC cards. J Grant will prompt M Yonge to go to sec formatted PWD. Goal PWD immediate, Target Standard 2005
AES-X144: Carriage of DSD audio data in AES47
No input to a PTD has been offered. C Chambers will prompt M. Storey for this, otherwise the project will be retired. Noted that product is already available.
AES-X148: Sample accurate timing in AES47
PTD has not been objected to. Grant to progress to secretariat for formatted PWD.
Goal: PWD from Sec asap. Target Standard 2005
LiaisonsIEC: TC100 met in Korea. Items discussed:
? PT61937 types for DTS ++ and AAC. (similar to SMPTE 337 etc but different header)
? 'Synchronisation', ie lip sync for consumer set-ups using a form of timecode. (From ATS advisory group to TC100)
? PT 60958 new copy control system
SMPTE: Yonge reported on a SMPTE standards meeting in the UK, 2004-09, with reference to lip sync. This is being seen as very important (at last) and needs close liaison and co-ordinated work between SMPTE and AES. Adding timecode to channel status or user may be involved. This is also being discussed at EBU. Various papers published over the last few years were discussed.
Lyman also reported that some SMPTE metadata might be contrived to manage audio track allocations.
EBU: See liaisons referred to in projects above
New ProjectsNo new projects were proposed
New BusinessThe chair requested that secretariat add the word "Synchronisation" to the scope of SC-02-02.
Next meeting is scheduled to be held in conjunction with the AES 118th Convention in Barcelona, Spain, 2005-05.