約 5,033,793 件
https://w.atwiki.jp/usb_audio/pages/14.html
原文：Audio Device Document 1.0(PDF) USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 i Universal Serial Bus Device Class Definition for Audio Devices Release 1.0 March 18, 1998 USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 ii Scope of This Release This document is the 1.0 release of this device class definition. Contributors Gal AshourIBM Corporation Billy BrackenridgeMicrosoft Corporation Oren TiroshAltec Lansing Craig ToddDolby Laboratories Remy ZimmermannLogitech Geert KnapenPhilips ITCL Interleuvenlaan 74-76 B-3001 Leuven-Heverlee BELGIUM Phone +32 16 390 734 Fax +32 16 390 600 E-mail Geert.Knapen(at)innet.be Revision History Revision Date Filename Author Description 0.1 Aug. 7, 95 Audio01.doc Geert Knapen Initial version. 0.2 Aug. 28, 95 Audio01.doc Geert Knapen Corrected typos.Attributes field from 8 to 16 bits.Auxiliary channel definition.Important issues added. 0.3 Oct. 9, 95 Audio03.doc Geert Knapen Intermediate version. 0.4 Nov. 29, 95 Audio04.doc Geert Knapen Change to Audio Function and Interface Property requests.Synch issues updated.Subclass divisions changed. 0.6 Dec. 19, 95 Audio06.doc Geert Knapen Listed remarks from last f2f Dec 7-8. 0.8 Dec. 12, 95 Audio08.doc Geert Knapen Incorporated changes, discussed at f2f Dec 6 95. 0.8a Jan. 20, 96 Audio08a.doc Geert Knapen Incorporated changes discussed at f2f Jan 18 95.Feedforward/feedback endpoint is now called synch endpoint. Feb. 5, 96 usb_au8a.doc Edited version of Audio08a.doc. 0.8b June. 5, 96 Audio08b.doc Geert Knapen Introduced new mixer concepts etc. 0.8c Oct. 1, 96 Audio08c.doc Geert Knapen Added appropriate descriptors and requests. 0.8d Dec. 1, 96 Audio08d.doc Geert Knapen Included remarks on 0.8c USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 iii Revision Date Filename Author Description 0.8e Jan. 1, 97 Audio08e.doc Geert Knapen Included remarks on 0.8d. Added Dolby Prologic and Up/Down-mix Processing Units. 0.8f Mar. 1, 97 Audio08f.doc Geert Knapen Removed associated interface. Added Set/Get Memory requests for all Entities. Introduced copyright protection, Audio Interface Collections. Added Stereo Widening Processing Unit. Added Reverb Processing Unit. Added Chorus Unit. Added Bass Boost and Loudness Controls. 0.9rc Apr. 1, 97 Audio09rc.doc Geert Knapen Changed Section 5 structure. Removed many request codes. Added requests for Reverb and Chorus. Changed Terminal request structure. Included all remarks from last meeting. 0.9 May 1, 97 Audio09.doc Geert Knapen Added wLockDelay and bLockUnits fields to CS endpoint descriptor. Added bit to CS endpoint descriptor to indicate packet size restrictions. Revised endpoint descriptors according to new CCS layout. Added Dynamic Range Compressor PU. 0.9CE Sep 1, 97 Audio09CE.doc Geert Knapen Copy-edited for publication on the web. 0.9a Oct 1, 97 Audio09a.doc Geert Knapen Incorporated RRs 1.0RC Mar 1, 98 Audio10RC.doc Geert Knapen Added examples and cleaned up the formatting. 1.0 Mar 18, 98 Audio10.doc Geert Knapen Changed all references to 1.0. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 iv Copyright © 1997, USB Implementers ForumAll rights reserved. INTELLECTUAL PROPERTY DISCLAIMER THIS SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER INCLUDING ANY WARRANTY OF MERCHANTABILITY, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION, OR SAMPLE. A LICENSE IS HEREBY GRANTED TO REPRODUCE AND DISTRIBUTE THIS SPECIFICATION FOR INTERNAL USE ONLY. NO OTHER LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY OTHER INTELLECTUAL PROPERTY RIGHTS IS GRANTED OR INTENDED HEREBY. AUTHORS OF THIS SPECIFICATION DISCLAIM ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF PROPRIETARY RIGHTS, RELATING TO IMPLEMENTATION OF INFORMATION IN THIS SPECIFICATION. AUTHORS OF THIS SPECIFICATION ALSO DO NOT WARRANT OR REPRESENT THAT SUCH IMPLEMENTATION(S) WILL NOT INFRINGE SUCH RIGHTS. Dolby™, AC-3™, Pro Logic™ and Dolby Surround™ are trademarks of Dolby Laboratories, Inc. All other product names are trademarks, registered trademarks, or service marks of their respective owners. Please send comments via electronic mail to techsup(atusb.org) USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 v Table of Contents Scope of This Release.........................................................................................................ii Contributors........................................................................................................................ii Revision History ..................................................................................................................ii Table of Contents ................................................................................................................v List of Tables ....................................................................................................................viii List of Figures...................................................................................................................xiii 1 Introduction ................................................................................................................14 1.1 Scope....................................................................................................................14 1.2 Purpose .................................................................................................................14 1.3 Related Documents ...............................................................................................14 1.4 Terms and Abbreviations.......................................................................................14 2 Management Overview...............................................................................................17 3 Functional Characteristics.........................................................................................18 3.1 Audio Interface Class.............................................................................................18 3.2 Audio Interface Subclass and Protocol...................................................................18 3.3 Audio Synchronization Types.................................................................................19 3.3.1 Asynchronous .................................................................................................19 3.3.2 Synchronous...................................................................................................19 3.3.3 Adaptive .........................................................................................................19 3.4 Inter Channel Synchronization ...............................................................................19 3.5 Audio Function Topology .......................................................................................20 3.5.1 Input Terminal ................................................................................................21 3.5.2 Output Terminal..............................................................................................21 3.5.3 Mixer Unit .......................................................................................................22 3.5.4 Selector Unit...................................................................................................22 3.5.5 Feature Unit....................................................................................................23 3.5.6 Processing Unit...............................................................................................23 3.5.7 Extension Unit ................................................................................................28 3.5.8 Associated Interfaces......................................................................................28 3.6 Copy Protection .....................................................................................................28 3.7 Operational Model .................................................................................................29 3.7.1 AudioControl Interface ....................................................................................30 3.7.2 AudioStreaming Interface ...............................................................................31 4 Descriptors .................................................................................................................36 4.1 Device Descriptor ..................................................................................................36 4.2 Configuration Descriptor ........................................................................................36 4.3 AudioControl Interface Descriptors.........................................................................36 4.3.1 Standard AC Interface Descriptor....................................................................36 4.3.2 Class-Specific AC Interface Descriptor ...........................................................37 4.4 AudioControl Endpoint Descriptors ........................................................................57 1 - 6 - 11 - 16 - 21 - 26 - 31 - 36 - 41 - 46 - 51 - 56 - 61 - 66 - 71 - 76 - 81 - 86 - 91 - 96 - 101 - 106 - 111 - 116 - 121 - 126 ここを編集
https://w.atwiki.jp/usb_audio/pages/15.html
原文：Audio Data Formats 1.0(PDF) USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 i Universal Serial Bus Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 ii Scope of This Release This document is the 1.0 release of this device class definition. Contributors Gal Ashour IBM Corporation Billy Brackenridge Microsoft Corporation Oren Tirosh Altec Lansing Craig Todd Dolby Laboratories Remy Zimmermann Logitech Geert Knapen Philips ITCL Interleuvenlaan 74-76 B-3001 Leuven-Heverlee BELGIUM Phone +32 16 390 734 Fax +32 16 390 600 E-mail Geert.Knapen(at)innet.be Revision History Revision Date Filename Author Description 0.1 Dec. 1, 96 Frmts01.doc Geert Knapen Initial version 0.2 Jan. 1, 97 Frmts02.doc Geert Knapen Corrected typos. 0.3 Mar. 1, 97 Frmts03.doc Geert Knapen Adapted template and contents to correspond with core document. 0.9rc Apr. 1, 97 Frmts09rc.doc Geert Knapen Brought in line with core document. Added Type II descriptors and requests. 0.9 May 1, 97 Frmts09.doc Geert Knapen Added details for MPEG and AC-3. Added format-specific requests. 0.9CE Sep 1, 97 Frmts09CE.doc Geert Knapen Copy-edited for publication on the web. 0.9a Oct 1, 97 Frmts09a.doc Geert Knapen Incorporated RRs 1.0RC Mar 1, 98 Frmts10RC.doc Geert Knapen Added the Transfer Delimiter concept. Cleaned up the formatting. 1.0 Mar 18, 98 Frmts10.doc Geert Knapen Changed all references to 1.0 USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 iii Copyright © 1997, USB Implementers ForumAll rights reserved. INTELLECTUAL PROPERTY DISCLAIMER THIS SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER INCLUDING ANY WARRANTY OF MERCHANTABILITY, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION, OR SAMPLE. A LICENSE IS HEREBY GRANTED TO REPRODUCE AND DISTRIBUTE THIS SPECIFICATION FOR INTERNAL USE ONLY. NO OTHER LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY OTHER INTELLECTUAL PROPERTY RIGHTS IS GRANTED OR INTENDED HEREBY. AUTHORS OF THIS SPECIFICATION DISCLAIM ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF PROPRIETARY RIGHTS, RELATING TO IMPLEMENTATION OF INFORMATION IN THIS SPECIFICATION. AUTHORS OF THIS SPECIFICATION ALSO DO NOT WARRANT OR REPRESENT THAT SUCH IMPLEMENTATION(S) WILL NOT INFRINGE SUCH RIGHTS. Dolby™, AC-3™, Pro Logic™ and Dolby Surround™ are trademarks of Dolby Laboratories, Inc. All other product names are trademarks, registered trademarks, or service marks of their respective owners. Please send comments via electronic mail to techsup(atusb.org) USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 iv Table of Contents Scope of This Release.........................................................................................................ii Contributors........................................................................................................................ii Revision History ..................................................................................................................ii Table of Contents ...............................................................................................................iv List of Tables .......................................................................................................................v 1 Introduction ..................................................................................................................6 1.1 Related Documents .................................................................................................6 1.2 Terms and Abbreviations.........................................................................................6 2 Audio Data Formats......................................................................................................8 2.1 Transfer Delimiter....................................................................................................8 2.2 Type I Formats ........................................................................................................8 2.2.1 USB Packets ....................................................................................................8 2.2.2 Audio Subframe................................................................................................9 2.2.3 Audio Frame.....................................................................................................9 2.2.4 Audio Streams ..................................................................................................9 2.2.5 Type I Format Type Descriptor .......................................................................10 2.2.6 Supported Formats .........................................................................................11 2.3 Type II Formats .....................................................................................................12 2.3.1 Encoded Audio Frames...................................................................................12 2.3.2 Audio Bitstreams.............................................................................................12 2.3.3 USB Packets ..................................................................................................13 2.3.4 Bandwidth Allocation.......................................................................................13 2.3.5 Timing ............................................................................................................13 2.3.6 Type II Format Type Descriptor ......................................................................13 2.3.7 Rate feedback ................................................................................................15 2.3.8 Supported Formats .........................................................................................15 2.4 Type III Formats ....................................................................................................26 2.4.1 Type III Format Type Descriptor .....................................................................26 3 Adding New Audio Data Formats ..............................................................................28 Appendix A. Additional Audio Device Class Codes .....................................................29 A.1 Audio Data Format Codes......................................................................................29 A.1.1 Audio Data Format Type I Codes....................................................................29 A.1.2 Audio Data Format Type II Codes...................................................................29 A.1.3 Audio Data Format Type III Codes..................................................................29 A.2 Format Type Codes ...............................................................................................30 A.1 Format-Specific Control Selectors .........................................................................30 A.3 ..................................................................................................................................30 A.3.1 MPEG Control Selectors.................................................................................30 A.3.2 AC-3 Control Selectors ...................................................................................30 USB Device Class Definition for Audio Data Formats Release 1.0 March 18, 1998 v List of Tables Table 2-1 Type I Format Type Descriptor........................................................................10 Table 2-2 Continuous Sampling Frequency ...................................................................10 Table 2-3 Discrete Number of Sampling Frequencies....................................................11 Table 2-4 Type II Format Type Descriptor.......................................................................13 Table 2-5 Continuous Sampling Frequency ...................................................................14 Table 2-6 Discrete Number of Sampling Frequencies....................................................14 Table 2-7 MPEG Format-Specific Descriptor ..................................................................16 Table 2-8 Set MPEG Control Request Values .................................................................18 Table 2-9 Get MPEG Control Request Values.................................................................18 Table 2-10 Dual Channel Control Parameter Block ........................................................19 Table 2-11 Second Stereo Control Parameter Block ......................................................19 Table 2-12 Multilingual Control Parameter Block...........................................................20 Table 2-13 Dynamic Range Control Parameter Block ....................................................20 Table 2-14 Scaling Control Parameter Block ..................................................................21 Table 2-15 High/Low Scaling Control Parameter Block .................................................21 Table 2-16 AC-3 Format-Specific Descriptor...................................................................22 Table 2-17 Set AC-3 Control Request Values..................................................................23 Table 2-18 Get AC-3 Control Request Values .................................................................23 Table 2-19 Mode Control Parameter Block .....................................................................24 Table 2-20 Dynamic Range Control Parameter Block ....................................................24 Table 2-21 Scaling Control Parameter Block ..................................................................25 Table 2-22 High/Low Scaling Control Parameter Block .................................................25 Table 2-23 Type III Format Type Descriptor....................................................................26 Table 2-24 Continuous Sampling Frequency .................................................................27 Table 2-25 Discrete Number of Sampling Frequencies..................................................27 Table A-1 Audio Data Format Type I Codes....................................................................29 Table A-2 Audio Data Format Type II Codes...................................................................29 Table A-3 Audio Data Format Type III Codes..................................................................29 Table A-4 Format Type Codes .........................................................................................30 Table A-5 MPEG Control Selectors .................................................................................30 Table A-6 AC-3 Control Selectors....................................................................................30 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
https://w.atwiki.jp/usb_audio/pages/50.html
原文：Audio Device Document 1.0(PDF) USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 106 Interface 0 Device Configuration AudioControl I/F Header Microphone IT Standard Descriptors Class-Specific Descriptors USB OUT SU AS I/F Alt. Setting 0 Interface 1 AS I/F Alt. Setting 1 General Type I Format Endpoint Endpoint ID1 ID2 Figure B-2 USB Microphone Descriptor Hierarchy B.3 Descriptors The following sections present all the descriptors that are used to describe the device. B.3.1 Device Descriptor Table B-1 USB Microphone Device Descriptor Offset Field Size Value Description 0 bLength 1 0x12 Size of this descriptor, in bytes. 1 bDescriptorType 1 0x01 DEVICE descriptor. 2 bcdUSB 2 0x0100 1.00 - current revision of USB specification. 4 bDeviceClass 1 0x00 Device defined at Interface level. 5 bDeviceSubClass 1 0x00 Unused. 6 bDeviceProtocol 1 0x00 Unused. 7 bMaxPacketSize0 1 0x08 8 bytes. 8 idVendor 2 0xXXXX Vendor ID. 10 idProduct 2 0xXXXX Product ID. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 107 Offset Field Size Value Description 12 bcdDevice 2 0xXXXX Device Release Code. 14 iManufacturer 1 0x01 Index to string descriptor that contains the string Your Name in Unicode. 15 iProduct 1 0x02 Index to string descriptor that contains the string Your Product Name in Unicode. 16 iSerialNumber 1 0x00 Unused. 17 bNumConfigurations 1 0x01 One configuration. B.3.2 Configuration Descriptor Table B-2 USB Microphone Configuration Descriptor Offset Field Size Value Description 0 bLength 1 0x09 Size of this descriptor, in bytes. 1 bDescriptorType 1 0x02 CONFIGURATION descriptor. 2 wTotalLength 2 0x0064 Length of the total configuration block, including this descriptor, in bytes. 4 bNumInterfaces 1 0x02 Two interfaces. 5 bConfigurationValue 1 0x01 ID of this configuration. 6 iConfiguration 1 0x00 Unused. 7 bmAttributes 1 0x80 Bus Powered device, not Self Powered, no Remote wakeup capability. 8 MaxPower 1 0x0A 20 mA Max. power consumption. B.3.3 AudioControl Interface Descriptor The AudioControl interface describes the device structure (audio function topology) and is used to manipulate the Audio Controls. B.3.3.1 Standard AC Interface Descriptor The AudioControl interface has no dedicated endpoints associated with it. It uses the default pipe (endpoint 0) for all communication purposes. Class-specific AudioControl Requests are sent using the default pipe. There is no Status Interrupt endpoint provided. Table B-3 USB Microphone Standard AC Interface Descriptor Offset Field Size Value Description USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 108 Offset Field Size Value Description 0 bLength 1 0x09 Size of this descriptor, in bytes. 1 bDescriptorType 1 0x04 INTERFACE descriptor. 2 bInterfaceNumber 1 0x00 Index of this interface. 3 bAlternateSetting 1 0x00 Index of this setting. 4 bNumEndpoints 1 0x00 0 endpoints. 5 bInterfaceClass 1 0x01 AUDIO. 6 bInterfaceSubclass 1 0x01 AUDIO_CONTROL. 7 bInterfaceProtocol 1 0x00 Unused. 8 iInterface 1 0x00 Unused. B.3.3.2 Class-specific AC Interface Descriptor The Class-specific AC interface descriptor is always headed by a Header descriptor that contains general information about the AudioControl interface. It contains all the pointers needed to describe the Audio Interface Collection, associated with the described audio function. Table B-4 USB Microphone Class-specific AC Interface Descriptor Offset Field Size Value Description 0 bLength 1 0x09 Size of this descriptor, in bytes. 1 bDescriptorType 1 0x24 CS_INTERFACE. 2 bDescriptorSubtype 1 0x01 HEADER subtype. 3 bcdADC 2 0x0100 Revision of class specification - 1.0 5 wTotalLength 2 0x001E Total size of class specific descriptors. 7 bInCollection 1 0x01 Number of streaming interfaces. 8 baInterfaceNr(1) 1 0x01 AudioStreaming interface 1 belongs to this AudioControl interface. B.3.3.3 Input Terminal Descriptor This descriptor describes the Input Terminal that represents the microphone capsule, followed by the Ato- D converter. The resulting digital audio stream leaves the Input Terminal through the single Output Pin. The audio channel cluster contains a single logical channel (bNrChannels=1) and there is no spatial location associated with this mono channel (wChannelConfig=0x0000). USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 109 Table B-5 USB Microphone Input Terminal Descriptor Offset Field Size Value Description 0 bLength 1 0x0C Size of this descriptor, in bytes. 1 bDescriptorType 1 0x24 CS_INTERFACE. 2 bDescriptorSubtype 1 0x02 INPUT_TERMINAL subtype. 3 bTerminalID 1 0x01 ID of this Input Terminal. 4 wTerminalType 2 0x0201 Terminal is Microphone. 6 bAssocTerminal 1 0x00 No association. 7 bNrChannels 1 0x01 One channel. 8 wChannelConfig 2 0x0000 Mono sets no position bits. 10 iChannelNames 1 0x00 Unused. 11 iTerminal 1 0x00 Unused. B.3.3.4 Output Terminal Descriptor This descriptor describes the Output Terminal that represents the USB pipe to the Host PC. Its Input Pin is directly connected to the Output Pin of the Input Terminal (bSourceID= Input Terminal ID). Table B-6 USB Microphone Output Terminal Descriptor Offset Field Size Value Description 0 bLength 1 0x09 Size of this descriptor, in bytes. 1 bDescriptorType 1 0x24 CS_INTERFACE. 2 bDescriptorSubtype 1 0x03 OUTPUT_TERMINAL subtype. 3 bTerminalID 1 0x02 ID of this Output Terminal. 4 wTerminalType 2 0x0101 USB Streaming. 6 bAssocTerminal 1 0x00 Unused. 7 bSourceID 1 0x01 From Input Terminal. 8 iTerminal 1 0x00 Unused. B.3.4 AudioStreaming Interface Descriptor The AudioStreaming interface has two possible alternate settings. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 110 B.3.4.1 Zero-bandwidth Alternate Setting 0 Alternate setting 0 is a zero-bandwidth setting, used to relinquish the claimed bandwidth on the bus when the microphone is not in use. It is the default setting after power-up. The zero bandwidth is implemented by specifying that this alternate setting of the interface has no endpoints associated with it (bNumEndpoints=0). The collection of descriptors for this alternate setting reduces to the standard interface descriptor. B.3.4.1.1.1 Standard AS Interface Descriptor Table B-7 USB Microphone Standard AS Interface Descriptor (Alt. Set. 0) Offset Field Size Value Description 0 bLength 1 0x09 Size of this descriptor, in bytes. 1 bDescriptorType 1 0x04 INTERFACE descriptor. 2 bInterfaceNumber 1 0x01 Index of this interface. 3 bAlternateSetting 1 0x00 Index of this alternate setting. 4 bNumEndpoints 1 0x00 0 endpoints. 5 bInterfaceClass 1 0x01 AUDIO. 6 bInterfaceSubclass 1 0x02 AUDIO_STREAMING. 7 bInterfaceProtocol 1 0x00 Unused. 8 iInterface 1 0x00 Unused. B.3.4.2 Operational Alternate Setting 1 Alternate setting 1 is the operational setting of the interface. It contains the standard and class-specific interface and endpoint descriptors. B.3.4.2.1.1 Standard AS Interface Descriptor Table B-8 USB Microphone Standard AS Interface Descriptor Offset Field Size Value Description 0 bLength 1 0x09 Size of this descriptor, in bytes. 1 bDescriptorType 1 0x04 INTERFACE descriptor. 2 bInterfaceNumber 1 0x01 Index of this interface. 3 bAlternateSetting 1 0x01 Index of this alternate setting. 4 bNumEndpoints 1 0x01 One endpoint. 5 bInterfaceClass 1 0x01 AUDIO. 1 - 6 - 11 - 16 - 21 - 26 - 31 - 36 - 41 - 46 - 51 - 56 - 61 - 66 - 71 - 76 - 81 - 86 - 91 - 96 - 101 - 106 - 111 - 116 - 121 - 126 ここを編集
https://w.atwiki.jp/usb_audio/pages/28.html
原文：Audio Terminal Types 1.0(PDF) USB Device Class Definition for Terminal Types Release 1.0 March 18, 1998 11 Terminal Type Code I/O Description MiniDisk 0x0706 I/O Minidisk player. Analog Tape 0x0707 I/O Analog Audio Tape. Phonograph 0x0708 I Analog vinyl record player. VCR Audio 0x0709 I Audio track of VCR. Video Disc Audio 0x070A I Audio track of VideoDisc player. DVD Audio 0x070B I Audio track of DVD player. TV Tuner Audio 0x070C I Audio track of TV tuner. Satellite Receiver Audio 0x070D I Audio track of satellite receiver. Cable Tuner Audio 0x070E I Audio track of cable tuner. DSS Audio 0x070F I Audio track of DSS receiver. Radio Receiver 0x0710 I AM/FM radio receiver. Radio Transmitter 0x0711 O AM/FM radio transmitter. Multi-track Recorder 0x0712 I/O A multi-track recording system. Synthesizer 0x0713 I Synthesizer. USB Device Class Definition for Terminal Types Release 1.0 March 18, 1998 12 3 Adding New Terminal Types Adding new Terminal Types to this specification is achieved by proposing a fully documented Terminal Type to the Audio Device Class Working Group. Upon acceptance, the group will register the new Terminal Type (attribute a unique Terminal Type Code) and update this document accordingly. This process will also guarantee that new releases of generic USB audio drivers will support the newly registered Terminal Types. It is always possible to use vendor-specific definitions if the above procedure is considered unsatisfactory. 1 - 6 - 11 ここを編集
https://w.atwiki.jp/usbportable/pages/78.html
Audio Encoder (98/Me/2000/XP) 音声ファイル変換 公式サイト Monkey sAudio/Mp3/Ogg Vorbis/TwinVQ/WAVE/Windows Media Audio9/FLACの相互変換 音楽CD取り込み/MIDIの変換など AudioEncoderは、Monkey sAudio、Mp3、OggVorbis、TwinVQ、WAVE、WindowsMediaAudio9・FLAC に対応したエンコーダ/デコーダです。 また、音楽CDからの取り込みやAVIの音声部分、MIDIからの変換もできます。 もちろんタグ情報の読み書きに対応しているのでエンコード時にタグ情報を引き継ぐことができます。 Mp3のエンコードには、LAMEを使用します。(別途lame_enc.dllが必要)
https://w.atwiki.jp/usb_audio/pages/42.html
原文：Audio Device Document 1.0(PDF) USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 66 5.2.1.1 Set Request This request is used to set an attribute of a Control inside an Entity of the audio function. Additionally, the memory space attribute of an Entity itself can be set through this request. Table 5-1 Set Request Values bmRequest Type bRequest wValue wIndex wLength Data 00100001B Entity ID and Interface 00100010B SET_CUR SET_MIN SET_MAX SET_RES SET_MEM See following paragraphs Endpoint Length of parameter block Parameter block The bmRequestType field specifies that this is a SET request (D7=0b0). It is a class-specific request (D6..5=0b01), directed to either the AudioControl interface or an AudioStreaming interface of the audio function (D4..0=0b00001) or the isochronous endpoint of an AudioStreaming interface (D4..0=0b00010). The bRequest field contains a constant, identifying which attribute of the addressed Control or Entity is to be modified. Possible attributes for a Control are its · Current setting attribute (SET_CUR) · Minimum setting attribute (SET_MIN) · Maximum setting attribute (SET_MAX) · Resolution attribute (SET_RES) Possible attributes for an Entity are its · Memory space attribute (SET_MEM) If the addressed Control or Entity does not support modification of a certain attribute, the control pipe must indicate a stall when an attempt is made to modify that attribute. In most cases, only the CUR and MEM attribute will be supported for the Set request. However, this specification does not prevent a designer from making other attributes programmable. For the list of Request constants, refer to Section A.9, “Audio Class-Specific Request Codes.” The wValue field interpretation is qualified by the value in the wIndex field. Depending on what Entity is addressed, the layout of the wValue field changes. The following paragraphs describe the contents of the wValue field for each Entity separately. In most cases, the wValue field contains the Control Selector (CS) in the high byte. It is used to address a particular Control within Entities that can contain multiple Controls. If the Entity only contains a single Control, there is no need to specify a Control Selector and the wValue field can be used to pass additional parameters. The wIndex field specifies the interface or endpoint to be addressed in the low byte and the Entity ID or zero in the high byte. In case an interface is addressed, the virtual Entity ‘interface’ can be addressed by specifying zero in the high byte. The values in wIndex must be appropriate to the recipient. Only existing Entities in the audio function can be addressed and only appropriate interface or endpoint numbers may be used. If the request specifies an unknown or non-Entity ID or an unknown interface or endpoint number, the control pipe must indicate a stall. The actual parameter(s) for the Set request are passed in the data stage of the control transfer. The length of the parameter block is indicated in the wLength field of the request. The layout of the parameter block is qualified by both the bRequest and wIndex fields. Refer to the following sections for a detailed description of the parameter block layout for all possible Entities. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 67 5.2.1.2 Get Request This request returns the attribute setting of a specific Control inside an Entity of the audio function. Additionally, the memory space attribute of an Entity itself can be returned through this request. Table 5-2 Get Request Values bmRequest Type bRequest wValue wIndex wLength Data 10100001B Entity ID and Interface 10100010B GET_CUR GET_MIN GET_MAX GET_RES GET_MEM See following paragraphs Endpoint Length of parameter block Parameter block The bmRequestType field specifies that this is a GET request (D7=0b1). It is a class-specific request (D6..5=0b01), directed to either the AudioControl interface or an AudioStreaming interface of the audio function (D4..0=0b00001) or the isochronous endpoint of an AudioStreaming interface (D4..0=0b00010). The bRequest field contains a constant, identifying which attribute of the addressed Control or Entity is to be returned. Possible attributes for a Control are its · Current setting attribute (GET_CUR) · Minimum setting attribute (GET_MIN) · Maximum setting attribute (GET_MAX) · Resolution attribute (GET_RES) Possible attributes for an Entity are its · Memory space attribute (GET_MEM) If the addressed Control or Entity does not support readout of a certain attribute, the control pipe must indicate a stall when an attempt is made to read that attribute. For the list of Request constants, refer to Section A.9, “Audio Class-Specific Request Codes.” The wValue field interpretation is qualified by the value in the wIndex field. Depending on what Entity is addressed, the layout of the wValue field changes. The following paragraphs describe the contents of the wValue field for each Entity separately. In most cases, the wValue field contains the Control Selector (CS) in the high byte. It is used to address a particular Control within Entities that can contain multiple Controls. If the Entity only contains a single Control, there is no need to specify a Control Selector and the wValue field can be used to pass additional parameters. The wIndex field specifies the interface or endpoint to be addressed in the low byte and the Entity ID or zero in the high byte. In case an interface is addressed, the virtual Entity ‘interface’ can be addressed by specifying zero in the high byte. The values in wIndex must be appropriate to the recipient. Only existing Entities in the audio function can be addressed and only appropriate interface or endpoint numbers may be used. If the request specifies an unknown or non-Entity ID or an unknown interface or endpoint number, the control pipe must indicate a stall. The actual parameter(s) for the Get request are returned in the data stage of the control transfer. The length of the parameter block to return is indicated in the wLength field of the request. If the parameter block is longer than what is indicated in the wLength field, only the initial bytes of the parameter block are returned. If the parameter block is shorter than what is indicated in the wLength field, the device indicates the end of the control transfer by sending a short packet when further data is requested. The layout of the parameter block is qualified by both the bRequest and wIndex fields. Refer to the following sections for a detailed description of the parameter block layout for all possible Entities. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 68 5.2.2 AudioControl Requests The following sections describe the possible requests that can be used to manipulate the audio Controls an audio function exposes through its Units. The same layout of the parameter blocks is used for both the Set and Get requests. 5.2.2.1 Terminal Control Requests The following paragraphs describe the Set and Get Terminal Control requests. 5.2.2.1.1 Set Terminal Control Request This request is used to set an attribute of a Terminal Control inside a Terminal of the audio function. Table 5-3 Set Terminal Control Request Values bmRequest Type bRequest wValue wIndex wLength Data 00100001B SET_CUR SET_MIN SET_MAX SET_RES CS Terminal ID and Interface Length of parameter block Parameter block The bRequest field indicates which attribute the request is manipulating. The MIN, MAX and RES attributes are usually not supported for the Set request. The wValue field specifies the Control Selector (CS) in the high byte and zero in the low byte. The Control Selector indicates which type of Control this request is manipulating. If the request specifies an unknown or unsupported CS to that Terminal, the control pipe must indicate a stall. For a description of the parameter block for the Terminal Controls, see Section 5.2.2.1.3, “Terminal Controls.” 5.2.2.1.2 Get Terminal Control Request This request returns the attribute setting of a specific Terminal Control inside a Terminal of the audio function. Table 5-4 Get Terminal Control Request Values bmRequest Type bRequest wValue wIndex wLength Data 10100001B GET_CUR GET_MIN GET_MAX GET_RES CS Terminal ID and Interface Length of parameter block Parameter block The bRequest field indicates which attribute the request is reading The wValue field specifies the Control Selector (CS) in the high byte and zero in the low byte. The Control Selector indicates which type of Control this request is addressing. If the request specifies an unknown or unsupported CS to that Terminal, the control pipe must indicate a stall. For a description of the parameter block for the Terminal Controls, see Section 5.2.2.1.3, “Terminal Controls.” USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 69 5.2.2.1.3 Terminal Controls For the time being, this specification defines only one Terminal Control. The following section presents a detailed description. 5.2.2.1.3.1 Copy Protect Control The Copy Protect Control is used to manipulate the Copy Protection Level (CPL) associated with a particular Terminal. Not all Terminals are required to support this Control. Only the Terminals that represent a connection to the audio function where audio streams enter or leave the audio function in a form that enables lossless duplication should consider Copy Protect Control. Input Terminals in this category should only support the Get Terminal Copy Protect Control request whereas Output Terminals in the same category should only support the Set Terminal Copy Protect Control request. A Copy Protect Control only supports the CUR attribute. The settings for the CUR attribute range from 0 to 2. This means · 0 CPL0 Copying is permitted without restriction. The material is either not copyrighted, or the copyright is not asserted. · 1 CPL1 One generation of copies may be made. The material is copyright protected and is the original. · 2 CPL2 The material is copyright protected and no digital copying is permitted. The Copy Protect Control honors the request to the best of its abilities. It may round the bCopyProtect attribute value to its closest available setting. It will report this setting when queried during a Get Control request. Table 5-5 Copy Protect Control Parameter Block Control Selector COPY_PROTECT_CONTROL wLength 1 Offset Field Size Value Description 0 bCopyProtect 1 Number The setting for the CUR attribute of the CopyProtect Control. 0x00 CPL0 0x01 CPL1 0x02 CPL2 5.2.2.2 Mixer Unit Control Requests The following paragraphs describe the Set and Get Mixer Unit Control requests. The Set Mixer Unit Control request can have two forms. The first form must be supported while the second form can be optionally implemented. The Get Mixer Unit Control request can have three forms. The first form must be supported, while the second and third form can be optionally implemented. If the second form of the Set request is implemented, the second form of the Get request must also be implemented. USB Device Class Definition for Audio Devices Release 1.0 March 18, 1998 70 5.2.2.2.1 Set Mixer Unit Control Request This request is used to set an attribute of a Mixer Control inside a Mixer Unit of the audio function. Table 5-6 Set Mixer Unit Control Request Values bmRequest Type bRequest wValue wIndex wLength Data 00100001B SET_CUR SET_MIN SET_MAX SET_RES ICN and OCN Mixer Unit ID and Interface Length of parameter block Parameter block The bRequest field indicates which attribute the request is manipulating. The MIN, MAX and RES attributes are usually not supported for the Set request. Because the Mixer Unit only contains a single type of Control, there is no need for a Control Selector. Instead, the wValue field specifies the Input Channel Number (ICN) in the high byte and the Output Channel Number (OCN) in the low byte of the Mixer Control to be influenced. The ICN is derived from both the input cluster number and the logical channel number within that cluster, according to the rules established in Section 4.3.2.3, “Mixer Unit Descriptor.” (ICN=u, OCN=v) If the request specifies an unknown ICN or OCN to that Unit or refers to a non-programmable Mixer Control in the Mixer Unit, the control pipe must indicate a stall. A special case arises when the Input Channel Number and Output Channel Number are both set to 0xFF. Then a single Set Mixer Unit Control request can be used to set an attribute of all the programmable Mixer Controls within the Unit. The number of parameters passed in the parameter block must exactly match the number of programmable Mixer Controls in the Unit. If this is not the case, the control pipe must indicate a stall. The ordering of the parameters in the parameter block obeys the same rules as established for the bit ordering in the bmControls field of the Mixer Unit Descriptor. The parameter block must contain an attribute setting for every Mixer Control that has its bit set in the bmControls field. The previous description is referred to as the second form of the Set Mixer Unit Control request. For a description of the parameter block for the Set Mixer Unit Control request, see Section 5.2.2.2.3, “Mixer Control.” 5.2.2.2.2 Get Mixer Unit Control Request This request returns the attribute setting of a specific Mixer Control inside a Mixer Unit of the audio function. Table 5-7 Get Mixer Unit Control Request Values bmRequest Type bRequest wValue wIndex wLength Data 10100001B GET_CUR GET_MIN GET_MAX GET_RES ICN and OCN Mixer Unit ID and Interface Length of parameter block Parameter block The bRequest field indicates which attribute the request is reading Because the Mixer Unit only contains a single type of Control, there is no need for a Control Selector. Instead, the wValue field specifies the Input Channel Number (ICN) in the high byte and the Output Channel Number (OCN) in the low byte of the Mixer Control to be retrieved. The ICN is derived from both the input cluster number and the logical channel number within that cluster, according to the rules 1 - 6 - 11 - 16 - 21 - 26 - 31 - 36 - 41 - 46 - 51 - 56 - 61 - 66 - 71 - 76 - 81 - 86 - 91 - 96 - 101 - 106 - 111 - 116 - 121 - 126 ここを編集
https://w.atwiki.jp/gtavi_gta6/pages/924.html
Digital Den - The Home of Electrics 概要 解説 店舗、外見など 看板 概要 日本語：デジタル・デン 業種：小売業 所在地：各地 解説 電子機器販売店チェーン。 eFriend（$799）をはじめ、Genic Digital、Tinkle、Facade、Fruit、Badger、Whizなどの商品を販売している。 eFriendは、ソーシャルネットワーク用タブレット端末。 使用方法はLifeInvaderのCMを参照。 Genic Digitalは、GTASAやGTAIVにも登場した、カメラなど写真関連製品のメーカー。 ちなみにDenとは「趣味のための私室」という意味。デジタルを駆使して私室でナニをしているのかは…ご想像にお任せする。 店舗、外見など Textile Cityビンコ1の西向かい。 モデルはこちら 。 Pillbox Hill射撃練習場1の北西。Mile High Clubの東向かい。Premium Deluxe MotorsportとHookah Palaceの間。 Mirror Park理容店5の向かい。Bite!の隣り。 West VinewoodTequi-La-Laの東向かい。入れないBincoの西。 モデルはBoot Star 。 向かいのThe Generic HoteのモデルはThe Standard Hollywood 。 Little SeoulLucky Pluckerの西向かい。TW@の少し東。Hoard Houseの1階の角。 モデルはU-Lock StorageのQuor 。 Little Seoul Del Perro PlazaLimey sの東隣り。Rob s Liquorの西向かい。 モデルはSanta Monica Plaza 。 東向かい角のVinewood Pawn JewelryのモデルはBrothers Collateral Loans （Googleｽﾄﾘｰﾄﾋﾞｭｰ ）。その東隣りのVinewood Beauty Saron SupplyのモデルはAmerican Beauty Saron Supply 。 Morning Woodアミュネーション6の西隣り。入れないBincoの東。 「Crime Scene - Do Not Enter」（犯罪現場 - 立入禁止）と書かれた黄色のバリケードテープが貼られている。 看板
https://w.atwiki.jp/gtav/pages/924.html
Digital Den - The Home of Electrics 概要 解説 店舗、外見など 看板 概要 日本語：デジタル・デン 業種：小売業 所在地：各地 解説 電子機器販売店チェーン。 eFriend（$799）をはじめ、Genic Digital、Tinkle、Facade、Fruit、Badger、Whizなどの商品を販売している。 eFriendは、ソーシャルネットワーク用タブレット端末。 使用方法はLifeInvaderのCMを参照。 Genic Digitalは、GTASAやGTAIVにも登場した、カメラなど写真関連製品のメーカー。 ちなみにDenとは「趣味のための私室」という意味。デジタルを駆使して私室でナニをしているのかは…ご想像にお任せする。 店舗、外見など Textile Cityビンコ1の西向かい。 モデルはこちら 。 Pillbox Hill射撃練習場1の北西。Mile High Clubの東向かい。Premium Deluxe MotorsportとHookah Palaceの間。 Mirror Park理容店5の向かい。Bite!の隣り。 West VinewoodTequi-La-Laの東向かい。入れないBincoの西。 モデルはBoot Star 。 向かいのThe Generic HoteのモデルはThe Standard Hollywood 。 Little SeoulLucky Pluckerの西向かい。TW@の少し東。Hoard Houseの1階の角。 モデルはU-Lock StorageのQuor 。 Little Seoul Del Perro PlazaLimey sの東隣り。Rob s Liquorの西向かい。 モデルはSanta Monica Plaza 。 東向かい角のVinewood Pawn JewelryのモデルはBrothers Collateral Loans （Googleｽﾄﾘｰﾄﾋﾞｭｰ ）。その東隣りのVinewood Beauty Saron SupplyのモデルはAmerican Beauty Saron Supply 。 Morning Woodアミュネーション6の西隣り。入れないBincoの東。 「Crime Scene - Do Not Enter」（犯罪現場 - 立入禁止）と書かれた黄色のバリケードテープが貼られている。 看板
https://w.atwiki.jp/usb_audio/pages/65.html
原文：Audio Devices Rev. 2.0 Spec and Adopters Agreement(ZIP) Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 26 Offset Field Size Value Description 4 qNanoSeconds 8 Number Offset in nanoseconds from the beginning of the audio stream. Note Timing information is intrinsically provided by the isochronous data transport mechanism itself (packets are synchronized to the USB SOF and the number of samples per packet is an overall measure of the audio data sampling rate). However, the high resolution presentation timestamp could potentially be used to deliver more accurate instantaneous timing information to the sink or to report a (constant) delay between the moment of transport over the USB and the moment of actual rendition. Care must be taken to ensure that the information contained in the Packet Header is at all times in agreement with the implicit timing information, delivered by the isochronous streaming mechanism. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 27 3 Adding New Audio Data Formats Adding new Audio Data Formats to this specification is achieved by proposing a fully documented Audio Data Format to the Audio Device Class Working Group. Upon acceptance, they will register the new Audio Data Format (attribute a unique bit position in the bmFormats field of the class-specific AS interface descriptor) and update this document accordingly. This process will also guarantee that new releases of generic USB audio drivers will support the newly registered Audio Data Formats. It is always possible to use vendor-specific definitions if the above procedure is considered unsatisfactory. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 28 4 Adding New Side Band Protocols Adding new Side Band Protocols to this specification is achieved by proposing a fully documented Side Band Protocol to the Audio Device Class Working Group. Upon acceptance, they will register the new Side Band Protocol (attribute a unique SideBandProtocol constant) and update this document accordingly. This process will also guarantee that new releases of generic USB audio drivers will support the newly registered Side Band Protocols. It is always possible to use vendor-specific definitions if the above procedure is considered unsatisfactory. Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 29 Appendix A. Additional Audio Device Class Codes A.1 Format Type Codes Table A-1 Format Type Codes Format Type Code Value FORMAT_TYPE_UNDEFINED 0x00 FORMAT_TYPE_I 0x01 FORMAT_TYPE_II 0x02 FORMAT_TYPE_III 0x03 FORMAT_TYPE_IV 0x04 EXT_FORMAT_TYPE_I 0x81 EXT_FORMAT_TYPE_II 0x82 EXT_FORMAT_TYPE_III 0x83 A.2 Audio Data Format Bit Allocation in the bmFormats field A.2.1 Audio Data Format Type I Bit Allocations Table A-2 Audio Data Format Type I Bit Allocations Name bmFormats PCM D0 PCM8 D1 IEEE_FLOAT D2 ALAW D3 MULAW D4 Reserved. Must be set to 0. D30..D5 TYPE_I_RAW_DATA D31 A.2.2 Audio Data Format Type II Bit Allocations Table A-3 Audio Data Format Type II Bit Allocations Name bmFormats MPEG D0 Universal Serial Bus Device Class Definition for Audio Data Formats Release 2.0 May 31, 2006 30 Name bmFormats AC-3 D1 WMA D2 DTS D3 Reserved. Must be set to 0. D30..D4 TYPE_II_RAW_DATA D31 A.2.3 Audio Data Format Type III Bit Allocations Table A-4 Audio Data Format Type III Bit Allocations Name bmFormats IEC61937_AC-3 D0 IEC61937_MPEG-1_Layer1 D1 IEC61937_MPEG-1_Layer2/3 or IEC61937_MPEG-2_NOEXT D2 IEC61937_MPEG-2_EXT D3 IEC61937_MPEG-2_AAC_ADTS D4 IEC61937_MPEG-2_Layer1_LS D5 IEC61937_MPEG-2_Layer2/3_LS D6 IEC61937_DTS-I D7 IEC61937_DTS-II D8 IEC61937_DTS-III D9 IEC61937_ATRAC D10 IEC61937_ATRAC2/3 D11 TYPE_III_WMA D12 Reserved. Must be set to 0. D31..D13 A.2.4 Audio Data Format Type IV Bit Allocations Table A-5 Audio Data Format Type IV Bit Allocations Name bmFormats PCM D0 1 - 6 - 11 - 16 - 21 - 26 - 31 ここを編集
https://w.atwiki.jp/dccinfo/pages/14.html
Digital Command Controlとは DCC入門者がDCCに求めるもの、それはおおむね次の２点に集約されるだろう。 レイアウトのレール上に多数の列車を配置し、個別かつ自由に走らせる。 車両に多くの機能（ライト・サウンド・ギミック等）を搭載、制御する。 どちらも鉄道模型ファンが永年夢見てきたものの、従来の制御方式ではなかなか果たし得えるものではなかった。ところが1980年代に入り、マイコン技術が花開いていわゆるデジタル時代に突入すると、この夢も実現しうるものとなりはじめた。初期のデジタル制御こそ他のデジタル製品同様に混迷したものの、やがて淘汰が進み、より洗練されて進化を続けることができたのが、このDCC方式であった。 本項では、現在鉄道模型デジタル制御の主流となったDCCを、システム全体から概観的に解説してみたい。 DCC解説サイトへのLINK 当サイトの文字ばかりの解説はわかりにくいという方に、いくつかDCC入門記事掲載サイトをご紹介。ちゃんと図版付きで解説されています。 基本はやはりここでしょう ホビーセンターカトー「DCC情報」 自動運転システムの解説ですが、DCC関連がわかりやすい システムソフィア「AUTO RAIL 製品仕様」 ショップのサイトですが、実際の作業が写真付きで！ ジョーシン鉄道模型教室Vol.3 本項の目次 DCCの定義 DCCの歴史 従来のアナログ制御との違い DCCの原理 車載デコーダとアクセサリデコーダ フィードバック・双方向通信 DCCの定義 DCCとは、デジタルコマンドコントロール（Digital Command Control）の略語であり、コマンドコントロールとは特定の鉄道模型車両に命令を与えることで個別に操作する技術を指す。よってDCCの一般的な語義としては、鉄道模型車両に対しデジタル信号による命令を与え、個別に制御するための技術および装置･システム全般を指すことになる。この意味ではデジタル列車制御（Digital Train Control）等の用語とほぼ同義となるが、近年では特にNMRA（全米鉄道模型協会）が標準規格化したデジタル制御技術および装置、システムを指すケースがほとんどであり、当サイトでも特に注釈のない限り、後者のNMRA DCCを指すこととする。 なお、当サイトでは前者の意味で使う場合には「デジタル制御」と表現し、従来のアナログ制御と区別する。また「アナログ・コマンドコントロール」についてはほとんど普及もなかったことから、特に略さず称する。 DCCの歴史 詳細は別項(こちら) 従来の技術では難しかった多列車同時運転やライトの明滅等の機能搭載を実現するため、デジタル技術を応用して鉄道模型を制御しようという試みは、すでに1978年前後には始まっており、過去に多くの製品が発表されてきた。 Dynatrol（当初はアナログ・コマンドコントロール）,CTC-16（アナログ）とRAILCOMMAND（開発メーカーCVP）,KATOデジタル,Zero 1(Hornby),MTC(Airfix社),FMZ（Fleischmann今でもTWINシステムとして残る）,Rail-Lynx（赤外線制御のもので、現在も販売）等、数え上げればきりがない程で、次世代の鉄道模型制御という夢は世界中で模索され続けた。 ところが、各メーカーの製品相互に互換性はほとんどなく（一部は当初から互換性を考慮されていたものもある）、性能的にも満足できないものであったことから、結局どの製品もあまり普及が進まなかった。しかし1980年代の終わり頃、ドイツのLenzレンツ社が、すでにメルクリン２線式として実績のあった自社のデジタル制御規格をNMRA全米鉄道模型協会に提示、これがNMRA主導による標準化作業を経て、1994年にデジタル制御方式の標準規格として採用されることとなった。さらにこれを欧州のMOROP欧州鉄道模型連盟でもNEM欧州鉄道模型標準規格として採用、事実上の世界標準としてのDCCが成立するに至り、世界中のメーカーがDCC規格に準じた商品を開発･発売を開始、これが市場に受け入れられて一気に普及することとなった。 その後日本では、鉄道模型大手のKATO社が独自のKATOデジタルを放棄して米国Digitraxデジトラックス社製品の輸入販売を開始、これに先んじて輸入商社の熊田貿易も、Lenz社DCC製品の輸入販売を始めた。DCC以外の規格によるデジタル制御は現在日本では販売されていない（メルクリン製品を除く）ことから、日本でもDCCが標準規格として(普及度はともかく）認知されるに至っている。 現在、DCC以外に広く一般的に使われているデジタル制御方式としては、ドイツのメルクリン社〈及びTrix社）製品に使われるいくつかの規格（mfxやSELECTRIX等）があるが、これら以外の方式や規格はほぼ淘汰されつくしており、市場で見かけることもほとんどなくなった。 従来のアナログ制御との違い 従来方式（特に直流２線方式=DC方式）では、コントローラ（パワーパック等とも呼ぶ）は線路にかける電圧を制御し、その電圧は車両の車輪を経由して車両内蔵のモーターに伝って、これを回転させる。この線路電圧を変化させることで車両の速度を増減させ、車両の進行方向は電圧の正負によって決まる。要するにレールをリード線の一部としてコントローラが直接モーターを回転制御しているわけである。線路電圧は特に符号化（デジタル化）されることもなくアナログ信号のままコントローラから送られるので、従来の制御方式をアナログ式またはアナログ制御と呼ぶこともある。 この方法では、普通は一対のレールにはひとつの電源電圧という情報しか載せることができない。このため、同一線路上のすべての車両は同じ電圧で走ることになり、個別にコントロールすることはできない。（高周波等による個別コントロールの試みもあったが、車載装置が大きくならざるを得ない、同時制御台数があまり増やせない等により、一般化しなかった） DCCでは、コントローラ（DCCではキャブもしくはスロットルと呼ぶ）の操作入力内容はDCC信号に符号化され、線路に電源として供給されている交流電流を搬送波として、線路に送られる。各車両には車載デコーダと呼ばれるマイコン（超小型のコンピュータだと考えればいい）が搭載されており、これが線路から受信した信号を解釈(デコード)して、モーター回転数等を制御する。（デコードのための装置＝デコーダ） すなわち、従来方式ではコントローラで直接車両のモーターを制御している(レールは単なるリード線）のに対し、DCCではコントローラはあくまで車両に対して送る信号を入力する端末装置に過ぎず、電力線兼信号線であるレールを介して信号を受信した車載デコーダが、車両を自立的に制御しているということであり、これが従来方式との最大の違いである。たとえて言うなら、従来方式はおもちゃのリモコンのようなものであり、DCCでは各車両に超小型のロボット機関士を積んでいるようなもの（現在はあまり賢いロボットではないが）。 DCCをはじめとするデジタル制御方式では、このような一見回りくどい制御方法をとることにより、従来方式では難しかった多列車同時運転や車両への機能搭載を実現しているわけである。 DCCの原理 鉄道模型をDCC化するのに欠かせない装置は、キャブ（コントローラ)、コマンドステーション、そしてデコーダである。 DCCの真髄は、このコマンドステーションとデコーダ間の通信にある、といっても過言ではない。コマンドステーションはDCCシステム全体を司る中央制御装置であり、デコーダはコマンドステーションから送られる命令信号に従って動作する出力端末。従来方式では電源電圧という単純な情報しか車両に送ることができなかったのに対し、DCCでは多様な情報を車両（正確には車載デコーダ）に送ることができるが、これはコマンドステーションとデコーダの通信に依存している。同一の線路上で多数のデコーダと通信できるのは信号多重化と呼ばれる技術を使っているためで、DCCに使われるのはPAM方式である。 原理を説明するためDCCの動作を順に追ってみる。 まずキャブの操作（ダイヤルによる速度や進行方向の決定、ボタンによるライト明滅、汽笛吹鳴等）は入力信号として、コマンドステーションに送られる。これをコマンドステーションはデコーダへの命令信号として組み立て、DCC信号に変換する。DCCシステムでは線路には電源用として常に交流（日本ではNゲージ、HOゲージとも12ボルトが一般的）が流されているが、コマンドステーションはこの交流を周波数変調し、コントローラの操作入力をデコーダへの命令パケット（パケットとは小包の意味だが、ここでは一まとまりのDCC信号のこと）として線路に送る。線路はDCCにおいては電力線と信号線を兼ねているので、その意味ではDCCは電力線通信をしているとも言えよう。 前述のとおり、各車両には車載デコーダと呼ばれるマイコン装置が搭載されているが、それぞれのデコーダには固有番号である「アドレス」が設定されている。コマンドステーションの送るパケットにはこのアドレスとデコーダへの命令（キャブの操作内容等）が含まれており、線路からパケットを受け取ったデコーダはまずアドレスを確認、そのパケットが自分宛のものであればその操作入力内容を解釈・実行に移る。 キャブの操作でもっとも重要なものは速度と進行方向の決定であろう。デコーダはコマンドステーションから送られた信号を解釈してこの操作内容を判断し、線路電源からモーター駆動用の電流を生成して車両内蔵モーターの回転を適切に制御する。つまりデコーダが車両の進行方向・速度を制御しているというわけである。 なお、一般的なデコーダはこのときPWMという擬似的な電圧制御によりモーターを駆動しているが、これはPWMがマイコンにより制御しやすいからという理由のほかに、低回転からモータートルクを得られるというメリットもある。 モーター駆動以外の各種機能はファンクションと呼ばれる。最も一般的なファンクションは前照灯のオン・オフであり、他にも多様なサウンド（汽笛等）やパンタグラフの昇降といったギミックのファンクションもある。これらの操作入力もDCC信号として送られ、デコーダが受信・解釈し、各機能を制御する。ただし、それぞれの機能がもともとその車両に備わっていなかったり（ライト非搭載車両等）、デコーダにファンクションを制御する能力がなかったりすれば（モーター専用デコーダもある）その操作は無視される。 車載デコーダとアクセサリデコーダ 前述のように車両に搭載され、モーターやファンクションを制御するデコーダを、特に車載デコーダ（英語ではMobile Decoder）と呼び、単にデコーダと称する場合は通常この車載デコーダを指す。車載デコーダにはモーター制御のみ、またはファンクション制御のみのものもある。 これとは別に、電動ポイントなど、レイアウトに設置されたアクセサリ・ギミックを制御するためのデコーダもあり、アクセサリデコーダ（英語ではStationary Decoderとも）と呼ぶ。ただアクセサリデコーダは、車両制御にDCCを導入したからといって必ずレイアウトにも導入する必要があるわけではなく、ポイントは従来のアナログ用ポイントスイッチで制御する等、従来の電気設備をそのまま使うことも、なんら問題なく可能である。 フィードバック・双方向通信 キャブ（コントローラ）を入力端末、コマンドステーションを制御装置、デコーダを出力端末としたとき、情報の流れはキャブからデコーダへの一方通行となるのが一般的である。しかし、出力端末であるデコーダの動作状況を知る（線路上にあるデコーダのアドレスを知りたいとか、ポイントデコーダの変換方向を知りたい等、いわゆるフィードバック）ことも必要であったため、デコーダから制御装置であるコマンドステーション、さらにはキャブとの間の双方向通信機能が求められた。 もちろん従来のアナログ制御方式にはフィードバックなど望むべくもないことから、従来方式の置き換えとして発達してきたDCCには、元来双方向通信機能は極めて限定的にしかなく、デコーダの動作をモニタリングする方法すらなかった。（同じ信号を連続して送信することで、デコーダや通信の一時的な異常･トラブルに対応するようにしている） このため、Digitrax社（トランスポンディング）、Lenzレンツ社（RailCom）等が独自にフィードバック機能を開発、さらに現在では、Lenz社の規格をもとにNMRAが双方向通信(BiDi）として標準化作業を進めている。 双方向通信によるメリットはおおむね次のとおり。 レイアウト上にある車両のデコーダアドレスを知ることで、現在運転できる列車を、キャブの画面上で簡単に選択できるようになる。 車載デコーダの動作状態を受け取り、正常に機能していることを確認できる。 デコーダプログラムの際、同じコマンドを連続送信する必要がなくなり、迅速･確実化できる。 車両の速度等動作状態を知ったり、特定のブロックを走行している車両のアドレスを知ることで、パソコンソフトや追加機器と連携により自動運転や信号･閉塞制御等が簡単･確実になる。 アクセサリデコーダから情報を得ることで、ポイントの開通方向等、レイアウト上にある装置類の動作状況がわかる。 逆にデメリットとしては、双方向通信機能を導入するためにはデコーダやコマンドステーションの置き換えや装置の追加を要すること、導入による得られるメリットが必ずしも全てのユーザーに必要なものではないこと、すべてのデコーダが双方向通信した場合にノイズの多い線路経由の通信で十分な性能を維持できるか不安が残ること等があげられる。 このことから、現時点では双方向通信はまだまだ普及しているとは言い難く、将来についても未知数である。