Γιατί ένα immersive master περνά από waveform editor και κόβεται στο QC

Ένα immersive παραδοτέο μπορεί να ανοίξει σε έναν waveform editor, να δείξει δώδεκα ή δεκαέξι κομμάτια που μοιάζουν υγιή, να παίξει λογικά — και να απορριφθεί. Ο λόγος είναι δομικός: σε ένα αρχείο BW64 ο ήχος και τα μεταδεδομένα είναι δύο ξεχωριστά πράγματα που πρέπει να συμφωνούν απόλυτα, και τίποτα μέσα στη μορφή δεν τα υποχρεώνει να συμφωνούν. Ένας renderer επιλύει αναφορές. Ένας editor σχεδιάζει δείγματα. Διαφορετικές δουλειές — γι' αυτό ο έλεγχος ADM είναι έλεγχος ακεραιότητας αναφορών, όχι ακρόαση. Ακολουθεί τι λένε τα δύο πρότυπα, πού σπάνε οι αναφορές και ποιος έλεγχος πιάνει ποια αστοχία.

Τρία είδη ήχου, και γιατί η διάκριση κρίνει τα πάντα

Κάθε πρόβλημα immersive παράδοσης ξεκινά από σύγχυση για το ποιο από τα τρία πράγματα είναι ένα κομμάτι.

Ο ήχος βασισμένος σε κανάλια αντιστοιχίζει κάθε κομμάτι σε μια σταθερή θέση ηχείου. Το στέρεο είναι βασισμένο σε κανάλια, το ίδιο και το 5.1, το ίδιο και ένα bed 7.1.4. Η θέση είναι ψημένη μέσα στην ταυτότητα του καναλιού: το κομμάτι 3 είναι το κεντρικό ηχείο, και είναι το κεντρικό ηχείο σε κάθε σύστημα που το αναπαράγει. Το ITU-R BS.2051 το τυποποιεί αυτό για τα προηγμένα ηχητικά συστήματα, περιγράφοντας τις διατάξεις ως πλήθη στρωμάτων Upper + Middle + Bottom — το System A είναι 0+2+0 (στέρεο), το System B είναι 0+5+0 (5.1), το System D είναι 4+5+0, το System J είναι 4+7+0, το System H είναι 9+10+3, η διάταξη 22.2. Στο ADM αυτό είναι το typeDefinition DirectSpeakers, typeLabel 0001.

Ο ήχος βασισμένος σε αντικείμενα μεταφέρει ένα μονοφωνικό (ή πολυκάναλο pack) σήμα συν μεταδεδομένα θέσης που μεταβάλλονται στον χρόνο. Ο renderer αποφασίζει ποια πραγματικά ηχεία το αναπαράγουν, με βάση τη διάταξη που υπάρχει στον χώρο. Τίποτα στο κομμάτι δεν προϋποθέτει ηχείο. Αυτό είναι το typeDefinition Objects, typeLabel 0003.

Ο ήχος βασισμένος σε σκηνή, στην πράξη τα Higher-Order Ambisonics, κωδικοποιεί ολόκληρο το ηχητικό πεδίο ως συνιστώσες σφαιρικών αρμονικών. Καμία συνιστώσα δεν αντιστοιχεί από μόνη της σε κατεύθυνση· η κατεύθυνση προκύπτει από τον γραμμικό συνδυασμό. Αυτό είναι το HOA, typeLabel 0004. Το ADM ορίζει επίσης Matrix (0002) για σήματα σε μήτρα, όπως Mid-Side ή Lt/Rt, και Binaural (0005).

Η διάκριση δεν είναι ταξινομική άσκηση. Ένα παραδοτέο βασισμένο σε κανάλια αυτοπεριγράφεται αρκετά ώστε να επιβιώνει ως σκέτο WAV — βάλε σωστά τη σειρά των καναλιών και παίζει. Ένα παραδοτέο βασισμένο σε αντικείμενα ή σε σκηνή είναι χωρίς νόημα δίχως τα μεταδεδομένα του: ο ήχος είναι ένας σωρός αδιαφοροποίητων μονοφωνικών ροών, και το ADM είναι το μόνο που λέει κάτι διαφορετικό. Αυτή η ασυμμετρία είναι ο λόγος που υπάρχουν το BW64 και το ADM.

Το BW64 υπάρχει εξαιτίας ενός αριθμού 32 bit

Το κλασικό WAV είναι αρχείο RIFF. Το RIFF, από το 1991, βάζει πριν από κάθε chunk ένα πεδίο μεγέθους 32 bit. Τα τριάντα δύο bit διευθυνσιοδοτούν 4,294,967,296 byte — 4 GB — και αυτό είναι το απόλυτο ταβάνι τόσο για ολόκληρο το αρχείο όσο και για το chunk data μέσα του.

Για στέρεο στα 48 kHz / 24-bit ο ρυθμός δεδομένων είναι 288,000 byte ανά δευτερόλεπτο, οπότε τα 4 GB είναι περίπου 4 ώρες 8 λεπτά. Αδιάφορο. Για ένα master 128 κομματιών βασισμένο σε αντικείμενα στα 96 kHz / 24-bit ο ρυθμός είναι 36,864,000 byte ανά δευτερόλεπτο, και τα 4 GB είναι κάτω από δύο λεπτά — 116.5 δευτερόλεπτα.

Τα immersive master ξεπερνούν αυτό το όριο συστηματικά, και ένας writer WAV που το χτυπά παράγει είτε κολοβό αρχείο είτε αρχείο του οποίου τα δηλωμένα μεγέθη έχουν σιωπηλά αναδιπλωθεί. Η EBU το αντιμετώπισε πρώτη με το RF64 (EBU Tech 3306)· η ITU το πήγε παρακάτω ως Σύσταση ITU-R BS.2088 — το BW64.

Το κόλπο του φρουρού: 0xFFFFFFFF και ένα chunk ds64

Το BS.2088 είναι σαφές για τον μηχανισμό. «The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file», και τα αρχικά πεδία μεγέθους των 32 bit γίνονται σημαίες διαφυγής: «If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead.»

Αυτό είναι όλο το κόλπο, και αξίζει να ειπωθεί καθαρά: το BW64 δεν πλαταίνει τα πεδία μεγέθους του RIFF. Τα γεμίζει με 0xFFFFFFFF ως φρουρό και βάζει τα πραγματικά μεγέθη των 64 bit σε ένα chunk ds64 που πρέπει να κάθεται πρώτο μέσα στο αρχείο. Έτσι, ένα αρχείο BW64 κάτω από 4 GB είναι συμβατό byte προς byte με έναν αναγνώστη WAV από κάθε άποψη εκτός από την υπογραφή των τεσσάρων χαρακτήρων. Πολλά εργαλεία το δέχονται· κάποια πεισματικά όχι.

Τα chunk, και εκείνο που είναι ακριβώς 40 byte ανά εγγραφή

Κατά το BS.2088, ένα αρχείο BW64 αναμένεται να περιέχει τουλάχιστον ds64, fmt , chna, axml (με τα bxml και sxml ως εναλλακτικούς φορείς μεταδεδομένων) και τα δεδομένα κυματομορφής.

Το ds64 πρέπει να είναι το πρώτο chunk μετά την υπογραφή, γιατί ο αναγνώστης πρέπει να ξέρει τα πραγματικά μεγέθη πριν μπορέσει να διατρέξει οτιδήποτε άλλο. Μεταφέρει χαμηλά και υψηλά μισά των 32 bit για το μέγεθος όλου του αρχείου και για το μέγεθος του data, συν έναν πίνακα εγγραφών ChunkSize64 για κάθε άλλο υπερμεγέθη chunk — ένα chunk axml που περιγράφει χιλιάδες αντικείμενα με αυτοματισμό ακριβείας δείγματος μπορεί το ίδιο να πλησιάσει ή να ξεπεράσει τα 4 GB.

Το fmt είναι το τυπικό chunk μορφής WAVE — μορφή δείγματος, ρυθμός δειγματοληψίας, πλήθος καναλιών, bit ανά δείγμα, block align. Είναι η μόνη έγκυρη δήλωση για το πόσα διαπλεγμένα κανάλια υπάρχουν στο data. Όλα τα επόμενα είναι μεταδεδομένα για αυτά τα κανάλια, και τα μεταδεδομένα μπορούν να λένε ψέματα.

Το chna είναι η γέφυρα ανάμεσα στα φυσικά κομμάτια και στο ADM. Μετά τα ckID, ckSize, ένα numTracks των 2 byte και ένα numUIDs των 2 byte, κρατά έναν επίπεδο πίνακα εγγραφών audioID σταθερού πλάτους, καθεμιά ακριβώς 40 byte:

2 + 12 + 14 + 11 + 1 = 40. Τα πλάτη δεν είναι συμβουλευτικά: είναι ASCII σταθερού πλάτους, και ένας writer που βγάζει UID 13 χαρακτήρων έχει παραγάγει κατεστραμμένο πίνακα, όχι ελαφρώς ασυνήθιστο.

Μετράει και η σύμβαση των αναγνωριστικών. Τιμές 0x0FFF και κάτω παραπέμπουν στους κοινούς ορισμούς του ADM — τις τυποποιημένες, προκαθορισμένες μορφές καναλιών και pack — ενώ 0x1000 και πάνω δηλώνουν προσαρμοσμένους ορισμούς που πρέπει να υπάρχουν στο axml. Το AP_00010003 είναι 5.1 κατά κοινό ορισμό και δεν χρειάζεται XML· το AP_00031001 είναι προσαρμοσμένο pack αντικειμένων και χρειάζεται XML, αλλιώς κρέμεται.

Το numUIDs μπορεί επίσης νόμιμα να ξεπερνά το numTracks: η καθοδήγηση της EBU σημειώνει ότι όπου «the audio elements of a track may be [defined] differently in the course of a file … there will be a different UID for each definition», άρα ένα trackIndex μπορεί να εμφανίζεται σε πολλές εγγραφές. Εργαλεία QC που υποθέτουν ένα UID ανά κομμάτι σημαδεύουν σωστά αρχεία ως χαλασμένα.

Το axml είναι ένα έγγραφο XML σε UTF-8 που περιέχει το δέντρο <audioFormatExtended>. Αυτό είναι το ADM, και εκεί ζουν ουσιαστικά όλες οι ενδιαφέρουσες αστοχίες. Το data είναι σκέτο διαπλεγμένο PCM· τίποτα μέσα του δεν ξέρει τίποτα για αντικείμενα.

Σειρά: ds64 πρώτο, πάντα· fmt πριν από το data. Όμως το axml μπορεί νόμιμα να κάθεται μετά το data, και συχνά κάθεται, γιατί — όπως παρατηρεί το BS.2088 — κατά την εγγραφή «the XML metadata will likely be of an unknown length.» Ένα αρχείο με το axml στην ουρά δεν είναι κακοσχηματισμένο, αλλά ένας αναγνώστης που σαρώνει μόνο το πρώτο megabyte θα αναφέρει ότι δεν υπάρχει καθόλου ADM. Αυτό εξηγεί ένα εκπληκτικό μερίδιο των αναφορών «το αρχείο μου δεν έχει μεταδεδομένα».

Το ADM είναι γράφος, και οι αστοχίες είναι σπασμένες ακμές

Η ιεραρχία του ITU-R BS.2076 τρέχει audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat, με το audioTrackUID ως φύλλο και ως το μόνο στοιχείο που αντιστοιχεί σε φυσικό κομμάτι.

Αυτό είναι γράφος αναφορών, όχι ένθετο έγγραφο, και κάθε σοβαρή αστοχία παράδοσης είναι μια σπασμένη ακμή του. Αυτό που κάνει επικίνδυνη μια αναφορά που κρέμεται είναι ότι δεν υπάρχει μία συμπεριφορά όταν σπάει. Ένας renderer που επιλύει ένα audioPackFormatIDRef το οποίο κατονομάζει pack απόν από το XML μπορεί να ματαιώσει την ανάλυση και να απορρίψει το αρχείο· μπορεί να παραλείψει το αντικείμενο και να αποδώσει όλα τα υπόλοιπα, παράγοντας μια μίξη που σιωπηλά της λείπει ένα stem· ή μπορεί να πέσει πίσω στους κοινούς ορισμούς, να βρει αναγνωριστικό στο προσαρμοσμένο εύρος από 0x1000 και πάνω χωρίς αντιστοιχία, και να βάλει σιωπή. Και τα τρία αποτελέσματα είναι «το αρχείο άνοιξε». Μόνο ένα πιάνεται με ακρόαση, και μόνο αν ξέρεις τι έπρεπε να υπάρχει.

Οι τέσσερις αστοχίες που εξηγούν τις περισσότερες απορρίψεις

Πλήθος κομματιών στο fmt που διαφωνεί με το chna. Το fmt .nChannels λέει 16· το chna.numTracks λέει 14. Το αρχείο είναι εσωτερικά ασυνεπές από τα πρώτα δύο chunk — συνήθως ένα bounce που άλλαξε πλήθος κομματιών μετά τη συγγραφή των μεταδεδομένων, ή ένα εργαλείο που πέταξε κομμάτια χωρίς να ξαναγράψει το chna. Ο εντοπισμός είναι ανάγνωση δύο ακεραίων και σύγκριση: ο φθηνότερος έλεγχος στη γραμμή, και πιάνει εντυπωσιακό ποσοστό αστοχιών. Επαλήθευσε ταυτόχρονα ότι κάθε trackIndex βρίσκεται μέσα στο 1 … fmt .nChannels.

Ένα audioTrackUID που δεν το αναφέρει κανένα αντικείμενο. Ένα UID στο chna που δεν το αναφέρει κανένα audioObject σημαίνει ότι υπάρχει ήχος τον οποίο δεν θα αποδώσει τίποτα· η καθρεφτική περίπτωση, ένα audioTrackUIDRef στο XML χωρίς αντίστοιχη εγγραφή chna, σημαίνει ότι τα μεταδεδομένα περιμένουν κομμάτι που δεν υπάρχει. Φτιάξε το σύνολο των UID από το chna και το σύνολο από το axml και πάρε τη συμμετρική διαφορά· πρέπει να είναι κενή. Το EBU Tech 3392 δηλώνει την πρόθεση απευθείας: «If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs.»

Χρονισμός μπλοκ που τρέχει ανάποδα. Το BS.2076 είναι κατηγορηματικό: «When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present.» Το EBU Tech 3392 το σφίγγει σε συνέχεια — «rtime + duration of an audioBlockFormat should match the rtime of the following block» — με το πρώτο μπλοκ ενός αντικειμένου να ξεκινά στο 00:00:00.00000, κανένα μπλοκ μικρότερο από ένα δείγμα, και τις διάρκειες να αθροίζουν στο γονικό audioObject. Διέτρεξε τα μπλοκ με τη σειρά του εγγράφου και βεβαιώσου ότι rtime[n] + duration[n] == rtime[n+1]. Οι αστοχίες έρχονται σε τρία σχήματα: κενά, όπου η συμπεριφορά του renderer είναι απροσδιόριστη και κάποιοι κρατούν την τελευταία θέση ενώ άλλοι σιγούν· επικαλύψεις, όπου τα μπλοκ μαλώνουν· και μπλοκ εκτός χρονολογικής σειράς, δηλαδή αυτοματισμός που πηδά προς τα πίσω μέσα στο πρόγραμμα.

Ένα bed που περιγράφεται στο XML και ποτέ δεν τυπώθηκε στον δίσκο. Το XML δηλώνει ένα pack DirectSpeakers 7.1.4 — δώδεκα κανάλια — αλλά τυπώθηκε μόνο το υποσύνολο 5.1, ή τα κανάλια ύψους ήταν σε σίγαση στο bounce και τυπώθηκαν ως ψηφιακό μαύρο. Ο γράφος αναφορών είναι άθικτος· ο ήχος δεν είναι. Οι δομικοί έλεγχοι δεν μπορούν να το πιάσουν αυτό: χρειάζεσαι ανάλυση ουσίας, μέτρηση του αν κάθε κανάλι που διεκδικεί ένα pack DirectSpeakers περιέχει καθόλου σήμα. Το ψηφιακό μαύρο σε δηλωμένο κανάλι bed δεν είναι αυτομάτως σφάλμα — μια νόμιμη μίξη μπορεί να αφήνει άδειο ένα πάνω-πίσω κανάλι — αλλά αξίζει πάντα ανθρώπινη απόφαση.

Τι είναι δημοσιευμένο για την immersive ένταση, και τι όχι

Ένα μέγεθος δεν επιβιώνει τη μετάβαση από το στέρεο, και αξίζει να ειπωθεί γιατί.

Το BS.1770-5 (Νοέμβριος 2023) είναι η τρέχουσα έκδοση· το BS.1770-4 έχει αντικατασταθεί, παρότι τα περισσότερα εγκατεστημένα μετρητικά εξακολουθούν να το αναφέρουν. Ο βασικός αλγόριθμός του σταθμίζει L, R και C στο 1.0 και Ls και Rs στο 1.41 (περίπου +1.5 dB), εξαιρεί το LFE, και έχει εμβέλεια «from one to five channels». Το BS.1770-5 προεκτείνεται πέρα από αυτό στα παραρτήματά του, καλύπτοντας τα προηγμένα ηχητικά συστήματα του BS.2051 και τον ήχο βασισμένο σε αντικείμενα — που πρέπει να αποδοθεί πριν μπορέσει να μετρηθεί. Η immersive ένταση δεν είναι επομένως ιδιότητα του αρχείου αλλά ενός render, και η αλλαγή της διάταξης-στόχου αλλάζει το μέγεθος. Μέτρα ένα render συμβατό με το BS.2127 σε μια κατονομασμένη διάταξη BS.2051 με μετρητικό BS.1770-5 και κατέγραψε και τα τρία στις σημειώσεις παράδοσης· το BS.2127 ορίζει τον renderer αναφοράς για ADM, και ο ανοιχτού κώδικα αδελφός του, ο EBU ADM Renderer (EBU Tech 3388), είναι ο πρακτικός τρόπος να πάρεις αναπαραγώγιμο μέγεθος.

Καμία υπηρεσία streaming μουσικής δεν δημοσιεύει στόχο ολοκληρωμένης έντασης για immersive παράδοση. Μεγέθη κυκλοφορούν σε φόρουμ και σε εκπαιδευτικό υλικό κατασκευαστών· κανένα δεν είναι δημοσιευμένη προδιαγραφή και αυτό το άρθρο δεν θα επαναλάβει κανένα σαν να ήταν. Δημοσιευμένο είναι ό,τι αφορά στέρεο βασισμένο σε κανάλια — ο ολοκληρωμένος στόχος του Spotify στα −14 LUFS με ανώτατη πραγματική κορυφή −1 dBTP, που σφίγγει στα −2 dBTP πάνω από −14 LUFS, και τα −16 LUFS του AES TD1008 για μουσική (το μέγεθός του −18 LUFS αφορά περιεχόμενο με έμφαση στον λόγο, και η δήλωση των −18 ως στόχου για μουσική είναι συχνό και σοβαρό λάθος).

Το Dolby Atmos είναι ιδιόκτητη, αδειοδοτούμενη τεχνολογία της Dolby Laboratories, και το Sony 360 Reality Audio είναι ιδιόκτητο σύστημα χτισμένο πάνω στο MPEG-H. Οι απαιτήσεις τους ορίζονται από τους κατόχους τους, αλλάζουν χωρίς αναφορά στα χρονοδιαγράμματα της ITU ή της EBU, και δεν δηλώνονται εδώ· καμία σχέση ή υποστήριξη δεν διεκδικείται. Διάβασε την τρέχουσα τεκμηρίωση του ίδιου του αδειοδότη.

Τι να ελέγξεις πριν το στείλεις

Πρώτα οι δομικοί έλεγχοι· είναι γρήγοροι και ακυρώνουν όλα τα επόμενα.

• Τα πρώτα τέσσερα byte είναι BW64. Αν διαβάζονται RIFF, είναι σκέτο WAV και δεν μπορεί να ξεπεράσει τα 4 GB.
• Το ds64 είναι το πρώτο chunk μετά την υπογραφή, τα μεγέθη του των 64 bit ταιριάζουν με τα μεγέθη του αρχείου και του data στον δίσκο, και κάθε υπερμεγέθες chunk εκτός του data έχει εγγραφή ChunkSize64 στον πίνακα.
• Εντόπισε ρητά το axml, ακόμη και μετά το data — ποτέ μη συμπεράνεις «δεν υπάρχει ADM» από μερική σάρωση.
• Ο ρυθμός δειγματοληψίας και το βάθος bit στο fmt ταιριάζουν ακριβώς με την προδιαγραφή παράδοσης. Καμία μετατροπή ρυθμού δειγματοληψίας μετά τη συγγραφή του ADM — ακυρώνει κάθε rtime και duration εκφρασμένο σε δείγματα.
• Το fmt .nChannels ισούται με το chna.numTracks· κάθε trackIndex είναι εντός εύρους και με βάση το 1.
• Κάθε εγγραφή chna είναι ακριβώς 40 byte με σωστά γεμισμένα πεδία σταθερού πλάτους, και κάθε packRef στο 0x1000 ή πάνω επιλύεται σε προσαρμοσμένο ορισμό που υπάρχει στο axml.
• Κάθε audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef και audioTrackUIDRef επιλύεται. Μηδέν ακμές που κρέμονται, προς οποιαδήποτε κατεύθυνση, χωρίς κυκλικές αναφορές.
• Οι μορφές καναλιών με πολλά μπλοκ φέρουν και rtime και duration σε κάθε μπλοκ· τα μπλοκ είναι συνεχόμενα και μονότονα· τα αντικείμενα ξεκινούν στο 00:00:00.00000.
• Κάθε κανάλι ενός δηλωμένου bed περιέχει αυτό που πρέπει. Ερεύνησε το ψηφιακό μαύρο.
• Το timecode εκκίνησης στο bext είναι συνεπές σε όλο το σετ, και τα στέρεο και binaural conform ξαναποδίδονται από το τρέχον master. Ένα conform 40 ms νωρίτερα από τον immersive γονέα του περνά έλεγχο παρουσίας αρχείου και κόβεται σε συγχρονισμένη ακρόαση.
• Βγάλε checksum για κάθε παραδοτέο, κράτα το manifest, και αρχειοθέτησε το ADM XML χωριστά από το BW64 — ένα XML που μπορείς να συγκρίνεις αξίζει αργότερα περισσότερο από ένα δυαδικό που μπορείς μόνο να ξαναπαρσάρεις.

Το BW64 και το ADM είναι ανοιχτά, δημοσιευμένα, ελεύθερα αναγνώσιμα πρότυπα, και αυτό αξίζει να το εκμεταλλευτείς: μπορείς να διαβάσεις μόνος σου το BS.2088 και το BS.2076, να παρσάρεις ένα chunk chna με σαράντα γραμμές κώδικα, και να επαληθεύσεις τι έγραψε πράγματι ο exporter ενός κατασκευαστή αντί για ό,τι ισχυρίστηκε το παράθυρό του. Σχεδόν όλες οι περιττές immersive απορρίψεις είναι σφάλματα ακεραιότητας αναφορών που ένας validator τα πιάνει σε λιγότερο από δευτερόλεπτο.

Ο δωρεάν inspector BW64/ADM της Mazufa στο mazufa.com/immersive-master-check παρσάρει τον container και τα μεταδεδομένα εξ ολοκλήρου στη δική σου συσκευή και δεν ανεβάζει τίποτα, πράγμα που τον κάνει χρησιμοποιήσιμο σε υλικό που συμβατικά δεν επιτρέπεται να βγει από το κτίριο. Η ίδια η Mazufa είναι δωρεάν για να κυκλοφορήσεις, παίρνει 0% προμήθεια, και λειτουργεί μόνο με πρόσκληση, με ανθρώπινη αξιολόγηση κάθε πλήρους αίτησης.

Πηγές

Συστάσεις ITU-R

• ITU-R BS.2088-2 (11/2025), Long-form file format for the international exchange of audio programme materials with metadata (BW64) — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2088-2-202511-I!!PDF-E.pdf
• ITU-R BS.2076-3 (02/2025), Audio Definition Model — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2076-3-202502-I!!PDF-E.pdf
• ITU-R BS.1770-5 (11/2023), Algorithms to measure audio programme loudness and true-peak audio level — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-5-202311-I!!PDF-E.pdf
• ITU-R BS.2051-2 (07/2018), Advanced sound system for programme production — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2051-2-201807-S!!PDF-E.pdf
• ITU-R BS.2127-1 (11/2023), Audio Definition Model renderer for advanced sound systems — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2127-1-202311-I!!PDF-E.pdf

Τεχνικά έγγραφα EBU

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (και συμπληρώματα), Specification of the Broadcast Wave Format — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3285s7.pdf
• EBU Tech 3392, ADM Broadcast Production Profile — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3392.pdf
• EBU Tech 3388, ADM Renderer for use in Next Generation Audio broadcasting — https://tech.ebu.ch/publications/tech3388
• EBU ADM Guidelines — CHNA chunk — https://adm.ebu.io/reference/excursions/chna_chunk.html
• EBU ADM Guidelines — BW64 and ADM — https://adm.ebu.io/reference/excursions/bw64_and_adm.html
• EBU ADM Guidelines — audioTrackUID — https://adm.ebu.io/reference/adm_elements/audio_track_uid.html
• libbw64 reference implementation — https://github.com/ebu/libbw64

AES

• AES TD1008, Recommendations for loudness of internet audio streaming and on-demand distribution — https://www.aes.org/community/technical-council/technical-document-aestd1008/

Τεκμηρίωση υπηρεσιών

• Spotify, Loudness normalization — https://support.spotify.com/us/artists/article/loudness-normalization/