The description of the bit_depth property in flow_audio_raw.json is a little vague.

[billt-hlit]

It's not clear to me if the bit_depth is supposed to refer to the total number of bits per sample as they appear on the wire, or if it refers to just the actual audio data and excludes any additional bits like padding or subframe information. I few additional words to clarify the field's intent would be helpful.

Thanks, Bill

[garethsb]

Agreed.

FWIW, the IS-05-02 test suite currently requires that for uncompressed audio the media_type (like audio/L24) matches the bit_depth exactly (i.e. must be 24 not 20).

https://github.com/AMWA-TV/nmos-testing/blob/97f3b452b8ba08588e4539ae702fbf589afe7378/nmostesting/suites/IS0502Test.py#L659-L678

[billt-hlit]

Thanks, Gareth. I'm actually looking at formats like AM824, which is a format supported by 2110-31, which has an audio sampling depth of 24 but where each sample takes 32 bits on the wire.

[garethsb]

I can't find a reference right now, but audio file/protocol formats often distinguish between (i.e. include both) quantization bit depth and sample or block size, esp. where samples include additional data/flag bits. AM824 includes up to 24-bit audio samples with 8 bits of metadata per sample. It does seem like we are potentially missing some parameters in NMOS, but to me, the current bit_depth parameter seems closest in meaning to number of bits of audio data per sample (thus 24 in the case of AM824). Definitely worthy of discussion.

[chappavarapu]

Hi Gareth, Any new update on this topic? I am interested in any new developments that has happened in the NMOS for AM824 format?

[garethsb]

Perhaps the current NMOS Stream Mappings activity group can agree and propose a resolution to this one...

[peterbrightwell]

@garethsb did anything get proposed in the BCP-006-* work yet? See also https://github.com/AMWA-TV/is-04/issues/195 re AM824. Architecture Review Group review: place on backlog