Review requested: audio/atrac3 media type registration

[actech]

Hi Mark,

We think that the proper streaming of ATRAC will be realized
by using SDP assuming that:

- Initializing audio decoder instance by "Media Type name : audio"
- If the "Media Subtype name" is one of the {atrac3, atrac-x,
   atrac-advanced-lossless}, activating corresponding decoder.
   Otherwise, the session will be closed.
- If the Parameter "rate" is not identical to D/A clock in the system, and
   if the sampling rate converter instance is available with the conversion
   ratio calculated by [D/A clock/rate parameter], it will be
   activated and start conversion task between decoder output and
   D/A converter input.

In case of missing of required parameter, or ATRAC media type, ATRAC
streaming session can not be started. The situation is exceptional,
and it is out of scope in our ATRAC payload format document.

As you say, the above processing may also be realized by +atrac
extension for particuler purpose, but our scope is more generic,
and described for lower level negotiation at the beginning of
the normal ATRAC streaming.

Best Regards,


> Hi,
> 
> On 2/27/08, actech <actech at jp.sony.com> wrote:
>> Hi Mark,
>>
>>  We think it is very useful that the all of decoding parameters
>>  are available before decoding, without any parsing of payload data.
>>  For example, if the receiver has only 48000Hz D/A clock, the
>>  receiver can activate sampling rate converter before 44100Hz decoding,
>>  or send back decoder capability(refusal of 44100Hz streaming) to
>>  sender side in SDP offer-answer exchange.
>>
>>  In addition, we made a discuss with AVT chair that also ATRAC3
>>  media type registration should have a bit-rate parameter
>>  even if it can be only 44100, considering the consistency
>>  that ATRAC-X and ATRAC Advanced Lossless media type have
>>  bit-rate parameter.
> 
> Ok, so there seems to be some kind of generic processing model here.
> Can you describe how that works?  I ask because I'm trying to figure
> out a) how a recipient should interpret the content when either a
> required parameter is missing or ATRAC3 content is transferred with an
> ATRAC media type, and b) if the generic processing model is of a
> variety that might benefit from a "+atrac" extension on media type
> names similar to "+xml" for XML content.
> 
> Keep in mind I know nothing about audio formats.
> 
> Thanks.
> 
> Mark.