IETF Logo Mail Archive

Re: [Cellar] ATRAC1 codec ID for Matroska

Moritz Bunkus <mo@bunkus.online> Tue, 04 October 2022 22:11 UTC

Return-Path: <mo@bunkus.online>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC943C14CE2B for <cellar@ietfa.amsl.com>; Tue, 4 Oct 2022 15:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.11
X-Spam-Level:
X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_SUSPICIOUS_NTLD=0.001, PDS_OTHER_BAD_TLD=1.997, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bunkus.online
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQyh6o_6lRJj for <cellar@ietfa.amsl.com>; Tue, 4 Oct 2022 15:10:59 -0700 (PDT)
Received: from liselle.bunkus.org (liselle.bunkus.org [IPv6:2a01:4f8:262:fc01::6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9D4C14F73B for <cellar@ietf.org>; Tue, 4 Oct 2022 15:10:58 -0700 (PDT)
Received: from sweet-chili.int.bunkus.org (sweet-chili.int.bunkus.org [IPv6:2003:a:f28:de01::4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) (Authenticated sender: email-relay) by liselle.bunkus.org (Postfix) with ESMTPSA id 8E13511EE40A; Wed, 5 Oct 2022 00:10:53 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bunkus.online; s=dkim; t=1664921453; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HGUtU8s/ioosq6mwN/XHTNQ4XNdXJA0RMxfJx0quuvw=; b=GIC7GJLrxQderT4TyLJQ6bpvcpdrCdoGyn5wUBTLw8q8V45RnMpjRPgPo6TUrNhk5jBcUS gRrcBDpk32H1gekLHxeJlNU0wetMEXqyyD+EzCzCVZmMP6Z9pWjAKjue1MgVnX94tDk2kK 4yxbg7XiJ+OnrRCWf8hebzV4j1YpSc4=
Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.int.bunkus.org (Postfix) with ESMTP id E8F8441584D1; Wed, 5 Oct 2022 00:10:51 +0200 (CEST)
References: <CAO1ejfRd+1BrJ+w6PMEor3b_8Q6593Mujna1a81AG0CarrGA=w@mail.gmail.com>
User-agent: mu4e 1.8.9; emacs 28.2
From: Moritz Bunkus <mo@bunkus.online>
To: Sir68k <sir68k@gmail.com>
Cc: cellar@ietf.org
Date: Wed, 05 Oct 2022 00:07:48 +0200
In-reply-to: <CAO1ejfRd+1BrJ+w6PMEor3b_8Q6593Mujna1a81AG0CarrGA=w@mail.gmail.com>
Message-ID: <87k05futn8.fsf@bunkus.online>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/X-2yMQhLZmRnT5VvkOugWgIbmM8>
Subject: Re: [Cellar] ATRAC1 codec ID for Matroska
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2022 22:11:04 -0000

Hey,

> We are unsure as to what the new ID should be. As ATRAC is a category of
> codecs, we were thinking of A_ATRAC/AT1. This of course might create
> confusion for ATRAC3, which is currently under A_REAL/ATRC but would be
> expected to be at A_ATRAC/AT3. Since ATRAC3Plus and ATRAC9 do exist, I
> believe this ID pattern makes the most sense in terms of future
> extensibility.

Yeah, A_REAL/ATRC exists, but it's a format no one uses these days —
RealMedia is dead. Therefore A_ATRAC/<something> is fine with me.

We don't really have a strongly enforced scheme for codec IDs, just a lose
sense of how the hierarchy should probably be. And your proposal fits it.

A_ATRAC/<something> has the advantage of being extensible with multiple
versions. A_REAL/ATRC should probably not have been named the way it has,
but such is life.

Kind regards,
mosu

v2.23.0 | Report a Bug | By Email