IETF Logo Mail Archive

Re: [Cellar] Last call on FLAC specification

Martijn van Beurden <mvanb1@gmail.com> Fri, 30 September 2022 07:00 UTC

Return-Path: <mvanb1@gmail.com>
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 435FFC1522C9 for <cellar@ietfa.amsl.com>; Fri, 30 Sep 2022 00:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.858
X-Spam-Level:
X-Spam-Status: No, score=-6.858 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 e_SZSdENQETN for <cellar@ietfa.amsl.com>; Fri, 30 Sep 2022 00:00:25 -0700 (PDT)
Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [IPv6:2607:f8b0:4864:20::1131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 C683CC1522C8 for <cellar@ietf.org>; Fri, 30 Sep 2022 00:00:25 -0700 (PDT)
Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-356abb37122so2723097b3.6 for <cellar@ietf.org>; Fri, 30 Sep 2022 00:00:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=S+cfmMrfyjmaKp4ux1bEKQFhN/2GuOiYEB5danu9sYo=; b=loF9qWCpgt5q71fEULeNgsTtfDGoNcqrMwoIAjKfuBHDHvtt54YOsSsWhpEu4LJHAW n2S5IO9gZ0gieQc/szZ/qxqh8hy80eO+bTh2XL2/XicXLbi81y8lP1YC3InUPv/ODT1M rHTmPZpx5js3uBj5MI3UgnXlTNYuh4i4VQxSuxmir6j4ATGvJqAiB6IZWhV5EDB+NChJ 5cTeagXE4Izl0Kz1BlmjaB0OZ4Rppnwc7BdMnmg4h2m5exgX5tDEbjo3WvubC1ZnTSTi bML2SLZGM8sQJc7DV9uXhNM6pz5HGwOTSQTjGpX46wOPpk1M7n/+KIowVF4dXVh4zWWw msBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=S+cfmMrfyjmaKp4ux1bEKQFhN/2GuOiYEB5danu9sYo=; b=gyXDcIykc31xT7yaJrRr6QUhCZdHYZlRDuVqojXVtHOPg0wbpxohNtoW8kLJu6OWXU llbFPFSgjL0IiTMstJV51VmQ6NlKfvS2uSA/8kt8i8ar6l4Nc3OAyDuxY0HIlFSSXvXU 5nHkZG3Q+0jMA3yHko+wR8W1bflwHse5ptI4fNIZVOLRGHTDxnzuC3TzOs0uvoIENvmV lt620xWoYXwMpl7f74YlyWCQy7+KZ5kje/ZkSLfMPbHP9/HCayICTNR0cK0aCL51WY9c Ca3hfn9mRQiHTV33cx4yTxUnOmnPL/RawtoditWHa/22LDU3uZ+pAcXDX+BdB0oA3Wtm rGpQ==
X-Gm-Message-State: ACrzQf0NGsVJHJAhRQbelNPKCkaoHh20rDCZZFsO7wi7vNh1eOMnNWb5 YgJcDfu2EoHDl8CMH+1+gCxmKV2/ygO3lpraArE=
X-Google-Smtp-Source: AMsMyM7Rspt3lFP4TS1iZp69TdaNgPkyy62qzJVP6pJzoxChD9XEnPd8BYO5mA94ucFbvbg8sbp0S3y1aiF4uEi/aoQ=
X-Received: by 2002:a81:7c45:0:b0:349:bc24:9591 with SMTP id x66-20020a817c45000000b00349bc249591mr7398740ywc.211.1664521224822; Fri, 30 Sep 2022 00:00:24 -0700 (PDT)
MIME-Version: 1.0
References: <CAAzqGd_Acroiu0ngUhvPTJHno=-vyccs-i9WYPLzeQ+Eba843g@mail.gmail.com> <CADQbU6-88CreFOy3LpzuXSz4yY75omx+8-m5u_Guf79Y7L9VaQ@mail.gmail.com> <CAAzqGd_j7u+=XRRS-iYHBgCyWKBWn9jtzBet88Ucd2yOWYmo2w@mail.gmail.com>
In-Reply-To: <CAAzqGd_j7u+=XRRS-iYHBgCyWKBWn9jtzBet88Ucd2yOWYmo2w@mail.gmail.com>
From: Martijn van Beurden <mvanb1@gmail.com>
Date: Fri, 30 Sep 2022 09:00:13 +0200
Message-ID: <CADQbU6-gJUztkL6=mcsVLFn1e-FXZOOxt8=yY_Q6Y5uy56hS_w@mail.gmail.com>
To: Martin Leese <martin.leese@stanfordalumni.org>
Cc: cellar@ietf.org
Content-Type: multipart/alternative; boundary="00000000000053a42905e9df8c83"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/HAqscikL9kICHB5wavpq4DTdXQ8>
Subject: Re: [Cellar] Last call on FLAC specification
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: Fri, 30 Sep 2022 07:00:26 -0000

Op do 29 sep. 2022 om 20:34 schreef Martin Leese <
martin.leese@stanfordalumni.org>:

> Yes, that would address my concern.
>
> Note also that the Microsoft document you
> reference above contains:
> #define SPEAKER_RESERVED  0x80000000
>
> In the RF64 spec this is changed to:
> #define SPEAKER_ALL               0x80000000
>
> You might also want to consider including this
> (in addition to SPEAKER_NONE 0x0).  In
> truth, I am not clear what SPEAKER_ALL
> actually means.
>

The RF64 specification actually defines a lot more channel mask bits than
just SPEAKER_ALL. It does also define downmixes, control samples and
bitstreams. The document says: Another “#define”, “SPEAKER_ALL” turns on all
loudspeakers (channels). In other words, a channel that must be played on
all speakers.

I agree with adding 0x0, but I'm not sure these RF64 defines would be a
good addition. I'd rather stick to what is defined in WAVEFORMATEXTENSIBLE.

Furthermore, the Microsoft specification allows for a channel mask having
more bits set than channels (MSBs must be ignored) and less bits than
channels (in which case last channel(s) are to be treated like they do not
belong to a speaker and ignored). I don't like the idea of allowing an
overdefined channel mask, and I'm also not sure whether it is a good idea
to encourage playback applications to just ignore certain channels.

Any thoughts?

v2.23.0 | Report a Bug | By Email