You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Samples would be a first step for basic detection.
For more, well... even before saying that priority will depends on the level of interest, we need to find specs...
I checked files and looks like that Auro-3D is hidden in DTS, without any spec available. As is, it is impossible to detect Auro-3D without big reverse engineering. Would not be done on free support.
I see no place in the file for encoded extra content.
on PCM yet.
If it is hidden in the raw content, this is something we won't implement without a sponsorship because it is not quick to implement, and for Auro3D on DTS-HDMA it would be even worse (not sure we want a DTS-HDMA decoder in MediaInfo, at least by default, we could add a plugin for that).
So in practice and due to how it is made, little chance that we detect Auro3D...
@JeromeMartinez But something strange when its in m2ts I can see Extension Substream with mediainfo but once its in any other container like mkv or mp4 can't see that anymore
The Auro-3D codec uses the 4 least significant bits (a noise floor you can’t hear) to put some metadata in, which allows us to reproduce each channel in high resolution quality.
It is embedded in 24-bit PCM which may be further encoded with lossless codecs.
There appears to be some pattern on the 3 least significant bits every 1000 samples looking at the supposedly silent part in the beginning of the video.
My understanding is that Auro3D just cheats by storing data in the lower bits, and in that case we need to decode, then reassemble, then catch the Auro3D (still no spec about it).
decoding is doable with the FFmpeg.
But without spec, no chance to catch the Auro3D bitstream (reverse engineering? May be easy to catch a magic code for indicating the presence of Auro3D, but likely not much more...)
I (the main dev) don't plan to do that without sponsorship, but open to patch if someone else does it.
I do not see any easily recognizable pattern in the beginning. So I guess whoever really wants Auro3D detection can look at all the bit-streams and try to find a pattern that can detect Auro3D with high accuracy without false positives.
The artistconnection service hosts some interesting files in MP4 containers with Auro-3D audio, which MediaInfo recognizes as a3ds. The MPC-HC player even displays the number of audio channels and the sample rate, but of course, it cannot play them. https://disk.yandex.ru/d/D057pW3thcrdBA
@cjee21's observation from May was right, and it resolves cleanly. I ended up chasing this for a media-server badge and have put the working method under MIT in case it is useful here: https://github.com/cinema-ONE/auro3d-detector
No spec, no SDK, no NDA — everything below was measured from purchased discs plus Auro's published white papers and patent US8620465.
Presence — an exact marker, not a statistical one
Each block opens with sixteen consecutive 1-bits in bit 0, written at the same sample offset in every carrier channel, on a regular grid at a constant phase.
Auro ch0: 0000 1111111111111111 0010 <- 16 ones, then a 0, then payload
Auro ch1: 0000 1111111111111111 0010 all channels, same instant
Auro ch2: 0000 1111111111111111 0000
DTS:X ch0: 0111 1010100100110000 0100 <- same samples, no structure
Two things make it safe to key on:
The grid is per-stream and must be discovered. This is why two files looked like they repeated at different intervals: 800, 960, 1000 and 1024 samples all occur, and 1000 and 1024 each appear at both 48 kHz and 96 kHz. It does not follow the sample rate, so a hard-coded 1000 passes the common case and silently misses the rest.
Require multi-channel phase agreement. A band-limited LFE throws long runs of 1s constantly — one DTS:X control gave 5,149 chance hits on its LFE alone. Requiring ≥2 channels to agree on one phase (mod grid) removed every false positive.
Also confirmed: bit-stuffing is real — every 16th bit after the sync is 0, in 200 of 200 blocks on a channel whose payload is otherwise random. That is what makes the sync unambiguous.
Cost
Decoding ~1 second via ffmpeg is enough (~48 syncs). The whole check ran in 0.13 s wall clock including the ffmpeg call, in unoptimised Python. That may make this cheaper than the plugin/decoder concern above — it needs a decode, but only a very short one.
Layout — works, but explicitly best-effort
Header bits 40–45, read in bit planes 0, 1 and 2 on a channel carrying no payload, map to the Auro layout. Bit 0 alone cannot separate 9.1 from 11.1.
bit 0
bit 1
bit 2
layout
101011
001001
001101
Auro 9.1
101000
001010
001101
Auro 10.1
101011
001010
001100
Auro 11.1
101011
001011
001101
Auro 13.1
101011
001011
001100
Auro 11.1 (7+4)
I want to be straight about the confidence split, because it is not the same for both halves:
Presence is solid. Confirmed in both directions by an Auro-3D-certified hardware decoder (StormAudio ISP Elite MK2, read over its TCP API) across 29 Auro tracks and 18 controls — TrueHD Atmos, AC-3, DTS:X and ordinary DTS-HD MA/HRA films.
Layout is best-effort. The mapping was derived by correlation against decoder-labelled streams, then blind-tested on ten it had never seen: nine valid trials, nine correct. It is not a parse of the format. CRC16-CCITT did not validate over any contiguous span I tried, so block framing is still not understood, and I cannot promise it generalises beyond the corpus.
Two dead ends are documented in the repo so nobody repeats them: a plausible rule based on which channels carry payload survived seventeen decoder readings and was then falsified, and the CRC brute-force found nothing.
Corpus was two Auro-3D demonstration Blu-rays swept track-by-track (175 streams), two commercial remuxes and a demo-trailer set. Happy to answer questions on any of it, or to run specific samples if that would help.
@cjee21 thank you — that is a much better answer than mine, and I should have found #2531 before posting. @almirus has the actual parse where I only had a correlate.
Rather than duplicate it, I ran Orua-D3 against my corpus as an independent check, because the one thing this thread has never had is verification against certified hardware rather than against another software implementation.
Orua-D3 vs a hardware decoder: 7 of 7
Ground truth is a StormAudio ISP Elite MK2 (Auro-3D certified), read over its TCP API — ssp.stream names the format and ssp.format gives the layout. Files it had never seen, two demonstration Blu-rays and two commercial remuxes:
file
StormAudio
Orua-D3
DragonHeart (1996), DTS-HD MA 7.1
13.1
7.1_5H_1T
match
Trinnov "Arrival" trailer
13.1
7.1_5H_1T
match
Daylight (1996), DTS-HD MA 5.1
11.1
5.1_5H_1T
match
Auro-3D Demo Disc 2014, stream 00000
9.1
5.1_4H
match
Auro-3D Demo Vol.2, stream 00021 (96 kHz)
9.1
5.1_4H
match
control — Dolby Atmos (TrueHD)
none
(nothing)
match
control — DTS:X
none
(nothing)
match
Both negatives are worth noting: the DTS:X control is a file that sits in a folder named Auro-3D, with Auro-3D in its filename, and contains no Auro layer at all. Orua-D3 correctly declines it.
So the ADOL/opcode-0x1E route reproduces a certified decoder exactly, on material chosen independently of it. If the blocker on #2531 is confidence rather than effort, that may help.
Why my own CRC attempt failed, since it may save someone else the time
I could not get CRC16-CCITT to validate over any contiguous span — seven variants, all start offsets to 47, lengths to 223. The reason is now obvious: @almirus computes it over all three bytes of every 24-bit sample (with & 0xFD on the first byte of the first 16), whereas I was searching spans of the extracted LSB bitstream. Wrong data domain — no search of my space could ever have found it.
For the record, the parts of my write-up that were independently correct still hold — the 16-sample sync, and that block size varies per stream (800/960/1000/1024 observed, with 1000 and 1024 at both 48 and 96 kHz). @almirus reads that properly from the header instead of discovering it empirically, which is strictly better.
I've updated my repo to point at Orua-D3 as the more complete work. Happy to run further samples against the hardware decoder if additional validation would be useful to #2531 — that is the one thing I can offer that a software-only comparison cannot.
Activity
JeromeMartinez commentedon Dec 14, 2021
Samples would be a first step for basic detection.
For more, well... even before saying that priority will depends on the level of interest, we need to find specs...
paxter commentedon Dec 15, 2021
I provided you three short samples.
The audio title will show you the used audio type.
Hope that helps. Let me know, if you need anything further.
JeromeMartinez commentedon Dec 18, 2021
I checked files and looks like that Auro-3D is hidden in DTS, without any spec available. As is, it is impossible to detect Auro-3D without big reverse engineering. Would not be done on free support.
paxter commentedon Dec 18, 2021
Hm ok. Bad news, but thanks for checking @JeromeMartinez.
paxter commentedon Feb 2, 2022
If needed, I can reupload the samples at any time. Just let me know.
paxter commentedon Feb 2, 2022
The files are mkv and the size is between 1-2 GB.
gphilipp commentedon Nov 29, 2024
@paxter would you mind sharing the samples again (links are dead)?
paxter commentedon Nov 29, 2024
@gphilipp sorry, I can't find them anymore.
jaloji commentedon Apr 30, 2025
@gphilipp @JeromeMartinez I've some Auro3D files if you want
JeromeMartinez commentedon Apr 30, 2025
Still interested (but with same issue about specs)
jerome@mediaarea.net if is can not be shared publicly.
jaloji commentedon Apr 30, 2025
@JeromeMartinez Sent.
Its Auro3D on DTS-HDMA, I don't have Auro3D on PCM yet.
JeromeMartinez commentedon May 1, 2025
I see no place in the file for encoded extra content.
If it is hidden in the raw content, this is something we won't implement without a sponsorship because it is not quick to implement, and for Auro3D on DTS-HDMA it would be even worse (not sure we want a DTS-HDMA decoder in MediaInfo, at least by default, we could add a plugin for that).
So in practice and due to how it is made, little chance that we detect Auro3D...
jaloji commentedon May 1, 2025
@JeromeMartinez But something strange when its in m2ts I can see Extension Substream with mediainfo but once its in any other container like mkv or mp4 can't see that anymore
JeromeMartinez commentedon May 1, 2025
Please share a m2ts, I'll check if I can find a similar "magic code" in DTS XLL extension (maybe it is inside the XLL extension somewhere).
4 remaining items
jaloji commentedon May 2, 2025
Oh yeah ok my bad :/
cjee21 commentedon May 14, 2025
Not sure how accurate is this post about how it is encoded.
cjee21 commentedon May 14, 2025
A more authoritative (Auro's founder) source: https://www.audioholics.com/audio-technologies/auro-3d-interview
It is embedded in 24-bit PCM which may be further encoded with lossless codecs.
almirus commentedon May 27, 2025
Here are a few more examples of files in Auro-3D format:
https://disk.yandex.ru/d/S4m06yu-VbhySA
The FLAC files were downloaded from the service:
https://music.artistconnection.net/dashboard/home/albums/2187/2816
cjee21 commentedon May 27, 2025
There appears to be some pattern on the 3 least significant bits every 1000 samples looking at the supposedly silent part in the beginning of the video.
JeromeMartinez commentedon May 27, 2025
My understanding is that Auro3D just cheats by storing data in the lower bits, and in that case we need to decode, then reassemble, then catch the Auro3D (still no spec about it).
decoding is doable with the FFmpeg.
But without spec, no chance to catch the Auro3D bitstream (reverse engineering? May be easy to catch a magic code for indicating the presence of Auro3D, but likely not much more...)
I (the main dev) don't plan to do that without sponsorship, but open to patch if someone else does it.
cjee21 commentedon May 27, 2025
I do not see any easily recognizable pattern in the beginning. So I guess whoever really wants Auro3D detection can look at all the bit-streams and try to find a pattern that can detect Auro3D with high accuracy without false positives.
cjee21 commentedon May 27, 2025
Looking at two files, I see some repeating pattern but the pattern is different for the two files and repeat at different sample intervals.
almirus commentedon May 27, 2025
The artistconnection service hosts some interesting files in MP4 containers with Auro-3D audio, which MediaInfo recognizes as
a3ds. The MPC-HC player even displays the number of audio channels and the sample rate, but of course, it cannot play them.https://disk.yandex.ru/d/D057pW3thcrdBA
LAV Splitter
cjee21 commentedon May 27, 2025
a3dsis "Auro-Cx 3D audio" in MP4 reg.Looks like a new codec
https://www.audioholics.com/news/auro-cx
JeromeMartinez commentedon May 27, 2025
I have channelcount / samplesize / samplerate in the MP4:
These fields use to be invalid in e.g. AAC when it is not MOV, so I don't read out them, but I can add an exception for this CodecID.
I need to update my DB :).
cinema-ONE commentedon Aug 22, 2026
@cjee21's observation from May was right, and it resolves cleanly. I ended up chasing this for a media-server badge and have put the working method under MIT in case it is useful here: https://github.com/cinema-ONE/auro3d-detector
No spec, no SDK, no NDA — everything below was measured from purchased discs plus Auro's published white papers and patent US8620465.
Presence — an exact marker, not a statistical one
Each block opens with sixteen consecutive 1-bits in bit 0, written at the same sample offset in every carrier channel, on a regular grid at a constant phase.
Two things make it safe to key on:
The grid is per-stream and must be discovered. This is why two files looked like they repeated at different intervals: 800, 960, 1000 and 1024 samples all occur, and 1000 and 1024 each appear at both 48 kHz and 96 kHz. It does not follow the sample rate, so a hard-coded 1000 passes the common case and silently misses the rest.
Require multi-channel phase agreement. A band-limited LFE throws long runs of 1s constantly — one DTS:X control gave 5,149 chance hits on its LFE alone. Requiring ≥2 channels to agree on one phase (mod grid) removed every false positive.
Also confirmed: bit-stuffing is real — every 16th bit after the sync is 0, in 200 of 200 blocks on a channel whose payload is otherwise random. That is what makes the sync unambiguous.
Cost
Decoding ~1 second via ffmpeg is enough (~48 syncs). The whole check ran in 0.13 s wall clock including the ffmpeg call, in unoptimised Python. That may make this cheaper than the plugin/decoder concern above — it needs a decode, but only a very short one.
Layout — works, but explicitly best-effort
Header bits 40–45, read in bit planes 0, 1 and 2 on a channel carrying no payload, map to the Auro layout. Bit 0 alone cannot separate 9.1 from 11.1.
101011001001001101101000001010001101101011001010001100101011001011001101101011001011001100I want to be straight about the confidence split, because it is not the same for both halves:
Two dead ends are documented in the repo so nobody repeats them: a plausible rule based on which channels carry payload survived seventeen decoder readings and was then falsified, and the CRC brute-force found nothing.
Corpus was two Auro-3D demonstration Blu-rays swept track-by-track (175 streams), two commercial remuxes and a demo-trailer set. Happy to answer questions on any of it, or to run specific samples if that would help.
cjee21 commentedon Aug 22, 2026
@cinema-ONE There is already a PR that mentioned this issue (see above) that has reverse engineered this as well and has CRC computation.
cinema-ONE commentedon Aug 22, 2026
@cjee21 thank you — that is a much better answer than mine, and I should have found #2531 before posting. @almirus has the actual parse where I only had a correlate.
Rather than duplicate it, I ran Orua-D3 against my corpus as an independent check, because the one thing this thread has never had is verification against certified hardware rather than against another software implementation.
Orua-D3 vs a hardware decoder: 7 of 7
Ground truth is a StormAudio ISP Elite MK2 (Auro-3D certified), read over its TCP API —
ssp.streamnames the format andssp.formatgives the layout. Files it had never seen, two demonstration Blu-rays and two commercial remuxes:13.17.1_5H_1T13.17.1_5H_1T11.15.1_5H_1T9.15.1_4H9.15.1_4HBoth negatives are worth noting: the DTS:X control is a file that sits in a folder named
Auro-3D, withAuro-3Din its filename, and contains no Auro layer at all. Orua-D3 correctly declines it.So the ADOL/opcode-
0x1Eroute reproduces a certified decoder exactly, on material chosen independently of it. If the blocker on #2531 is confidence rather than effort, that may help.Why my own CRC attempt failed, since it may save someone else the time
I could not get CRC16-CCITT to validate over any contiguous span — seven variants, all start offsets to 47, lengths to 223. The reason is now obvious: @almirus computes it over all three bytes of every 24-bit sample (with
& 0xFDon the first byte of the first 16), whereas I was searching spans of the extracted LSB bitstream. Wrong data domain — no search of my space could ever have found it.For the record, the parts of my write-up that were independently correct still hold — the 16-sample sync, and that block size varies per stream (800/960/1000/1024 observed, with 1000 and 1024 at both 48 and 96 kHz). @almirus reads that properly from the header instead of discovering it empirically, which is strictly better.
I've updated my repo to point at Orua-D3 as the more complete work. Happy to run further samples against the hardware decoder if additional validation would be useful to #2531 — that is the one thing I can offer that a software-only comparison cannot.
cjee21 commentedon Aug 22, 2026
There's more information here as well though I cannot read it without AI translator:
https://touch-max.ru/zvuk/auro-3d-kak-v-obychnom-pcm-pryachut-vysotnye-kanaly