Re: [Cellar] Last call on FLAC specification

Martin Leese <martin.leese@stanfordalumni.org> Thu, 29 September 2022 18:34 UTC

Return-Path: <mjleese@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 88A6FC1524A4 for <cellar@ietfa.amsl.com>; Thu, 29 Sep 2022 11:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.508
X-Spam-Level:
X-Spam-Status: No, score=-1.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, 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 (2048-bit key) header.d=gmail.com header.b=ZqOSEsDr; dkim=pass (2048-bit key) header.d=stanfordalumni-org.20210112.gappssmtp.com header.b=O5m4BJig
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 IyTmDG5VQzMl for <cellar@ietfa.amsl.com>; Thu, 29 Sep 2022 11:34:04 -0700 (PDT)
Received: from mail-oa1-x32.google.com (mail-oa1-x32.google.com [IPv6:2001:4860:4864:20::32]) (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 31BD7C1522D9 for <cellar@ietf.org>; Thu, 29 Sep 2022 11:34:04 -0700 (PDT)
Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-131de9fddbaso1774285fac.5 for <cellar@ietf.org>; Thu, 29 Sep 2022 11:34:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:sender :mime-version:from:to:cc:subject:date; bh=IIIk9sxE+8M33Mb2LH1zKF9RJebkuzqLKpwKaWM9Kgs=; b=ZqOSEsDrm8ZGKcP2h6i4YckpANAc8B/EMey+3Nca6t94yslNn0/Lw+jCUgD2gqgSoi aIZBlU+ecMgCceSQ/nq87Y6B9J2pWXo8vQrRX7FQ83/n+YCtrNTCA3Vq2vEpQ7T55KGK QVqYMOUXSADdrVAAUtiPwYnIsLKnr/1GaJt4XfxSxWLp/xLTpOJI1j38duHPp606FYG5 U0VLW1Rsm+WYhxLvF1vwO6D0jfs3TcanqhXl1r0hDEuzEBR1ZJdeq5yW8lssJENrofFk ZtcQ0WQGgR5uztt9sBsdXkf2hnVcOXtCLk8z6zEaNR5Y6tyAB2Q3rakkcJTlR1tEQe+4 Ghxw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stanfordalumni-org.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:sender :mime-version:from:to:cc:subject:date; bh=IIIk9sxE+8M33Mb2LH1zKF9RJebkuzqLKpwKaWM9Kgs=; b=O5m4BJigDlP0cnvwD9QtOhlKrO7UWb//KF35yoz1rz6diWfzone2j6jWil2Cdkdbcj QTATgUQf02KH4Go/jQJUXKZghjpAJWKQSrLeQo/BtqBBLSydJLSiukOMjXfCMh31DmFi 88k5aFmMAzs8doifKYVuyKMTMZpxld+P2tZDR/3EK3IOQhEFZJnXoHy4FAKtcQSlYDzk CV6UaFo6SIu/Vo6ja35SCEJUf584DgQs5oWWB+AxgdE7LOj92Bnd0mV73CNEsL/vAOLU TLjpMNx9ziOc4/j/gWH7ArJ3rYU9M2SOaxBKhYMhMILz7K4EWt+TnOc28pruT5WSrF6n kLYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:references:in-reply-to:sender :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=IIIk9sxE+8M33Mb2LH1zKF9RJebkuzqLKpwKaWM9Kgs=; b=cXUwUanj3jFV+j/yZkfKBXRF8ofX7EqFdZN9DoEBDE9WWLRX3vwHyAFevjwAg89Nqh u1SHC8Fqn9GyjVY8wKh0LFKslM6R/Kf3ctk9WTmCjXgq3+pN94qH6VUDuYp7tSUHG2fb rfelHDvWHs7rJC3rYNQud4Bm2jkNRy1sxCuqETCDWDwJYsHJRq9YUhWwi3c87h0rBHaA BtzPXg1m+EpFKv3fPezUkTM8D+QTyNpeer6OngeKOW8fw0RC/NxijXbdTPgXKcO6yi4/ XeuPQM5jwyYQzTq7nbp0Rp2bEOn0dtUPq+9OwZxznhNDYLRRUk8nyakBe0CzPLBAUcIK zyxQ==
X-Gm-Message-State: ACrzQf1iyZyXGySiJU/u60ZAPFa8dHLTnq42kORXW5Xg6Fkr/KjtpyWK JL0uDCTMTKzXmvgJz+vTEuNgGJsqs+r1K38sMIHSzmOZ
X-Google-Smtp-Source: AMsMyM55yGNp6KDh0OklIbiOLxey2LZXEO8SzGBaWBA/MTZ9YlNQdbL/euw5mCCkN7DqZFR8eMNohv/Y0IXHZF8mDYs=
X-Received: by 2002:a05:6870:33a9:b0:118:8dc6:300b with SMTP id w41-20020a05687033a900b001188dc6300bmr2761346oae.60.1664476443344; Thu, 29 Sep 2022 11:34:03 -0700 (PDT)
MIME-Version: 1.0
Sender: mjleese@gmail.com
Received: by 2002:a05:6830:2b07:0:0:0:0 with HTTP; Thu, 29 Sep 2022 11:34:02 -0700 (PDT)
In-Reply-To: <CADQbU6-88CreFOy3LpzuXSz4yY75omx+8-m5u_Guf79Y7L9VaQ@mail.gmail.com>
References: <CAAzqGd_Acroiu0ngUhvPTJHno=-vyccs-i9WYPLzeQ+Eba843g@mail.gmail.com> <CADQbU6-88CreFOy3LpzuXSz4yY75omx+8-m5u_Guf79Y7L9VaQ@mail.gmail.com>
From: Martin Leese <martin.leese@stanfordalumni.org>
Date: Thu, 29 Sep 2022 12:34:02 -0600
X-Google-Sender-Auth: i6MnsujQ9r6y6W7bJNwpOVABEno
Message-ID: <CAAzqGd_j7u+=XRRS-iYHBgCyWKBWn9jtzBet88Ucd2yOWYmo2w@mail.gmail.com>
To: cellar@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/dMFYRdkjPtZkH-qwia3eHmDLxk8>
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: Thu, 29 Sep 2022 18:34:08 -0000

On 9/29/22, Martijn van Beurden <mvanb1@gmail.com> wrote:
> Op do 29 sep. 2022 om 17:42 schreef Martin Leese <
...
>> 2.  Section 9.6.2, Table 7, Page 20.  FLAC files do not
>>     necessarily contain speaker feeds.  Examples of such
>>     files are a collection of audio stems or an Ambisonic
>>     B-Format recording.  Could we therefore please include
>>     a Channel description of SPEAKER_NONE with:
>>     WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x0
>>
>>     Given the way Table 7 is organised, It is not immediately
>>     clear to me how to include this.
>
> I don't know what the FLAC reference implementation or ffmpeg do in this
> regard, but the channel mask is copied directly from Microsoft's
> WAVEFORMATEXTENSIBLE structure. See here:
> https://learn.microsoft.com/en-us/previous-versions/windows/hardware/design/dn653308(v=vs.85)
>
> It says
>
>> If, for example in a multi-channel audio authoring application,
>> no speaker location is desired on any of the mono streams, the
>> dwChannelMask should explicitly be set to 0. A dwChannelMask of
>> 0 tells the audio device to render the first channel to the
>> first port on the device, the second channel to the second port
>> on the device, and so on. This also means that if the device
>> doesn't know how to process the raw audio streams, it should
>> not accept the multi-channel stream with a dwChannelMask of
>> 0. A device like a digital mixer or a digital audio storage
>> device (hard disk, ADAT, and so on) might want to accept
>> formats without particular speaker locations.
>
> Perhaps this and other comments about the channel mask should be added to
> the FLAC specification, rephrased.

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.

Regards,
Martin
-- 
Martin J Leese
E-mail: martin.leese  stanfordalumni.org
Web: http://members.tripod.com/martin_leese/