BW64 και ADM: τεχνικός οδηγός για την παράδοση καθηλωτικού ήχου

Οδηγός εργασίας για ηχολήπτες και μαστεροποιούς που ετοιμάζουν object-based (αντικειμενοστρεφή) ή scene-based παραδοτέα, και για μουσικούς που παρέλαβαν ένα «immersive deliverable» και τους ζητήθηκε να περάσει τεχνικό έλεγχο.

Η σύντομη απάντηση

Το ADM (Audio Definition Model, μοντέλο ορισμού ήχου) είναι ανοικτό πρότυπο μεταδεδομένων — Σύσταση ITU-R BS.2076 — που περιγράφει τι είναι κάθε κομμάτι ήχου μέσα σε ένα αρχείο: κανάλι σταθερού ηχείου, κινούμενο αντικείμενο ή συνιστώσα Ambisonics, και πώς όλα αυτά συντίθενται σε ένα πρόγραμμα. Τα μεταδεδομένα αυτά ταξιδεύουν ως XML μέσα σε έναν περιέκτη BW64 (Σύσταση ITU-R BS.2088), μια επέκταση 64 bit του RIFF/WAVE που ξεπερνά το όριο των 4 GB του κλασικού WAV. Οι καθηλωτικές παραδόσεις κόβονται στον έλεγχο όχι επειδή ακούγονται άσχημα, αλλά επειδή ο ήχος και τα μεταδεδομένα είναι δύο ξεχωριστά πράγματα που οφείλουν να συμφωνούν απόλυτα — και τίποτα μέσα στη μορφή του αρχείου δεν τα υποχρεώνει να συμφωνήσουν. Πλήθος καναλιών στο fmt που δεν συμπίπτει με τον πίνακα chna, ένα audioTrackUID που δεν το αναφέρει κανένα αντικείμενο, ένα block του οποίου ο χρόνος πηγαίνει προς τα πίσω, ένα bed που περιγράφεται στο XML αλλά δεν γράφτηκε ποτέ στον δίσκο: όλα αυτά είναι αόρατα σε έναν επεξεργαστή κυματομορφής και θανάσιμα για έναν renderer. Ο έλεγχος ADM είναι έλεγχος ακεραιότητας αναφορών, όχι ακρόαση.

1. Ο πρωτοψάλτης και οι ισοκράτες: η υποδειγματική ελληνική περίπτωση

Η βυζαντινή ψαλτική σε ορθόδοξο ναό δεν είναι απλώς ένα ωραίο παράδειγμα καθηλωτικής ηχογράφησης. Είναι η καθαρότερη περίπτωση που έχουμε στα ελληνικά για να δείξουμε γιατί η διάκριση καναλιού και αντικειμένου έχει νόημα, επειδή εδώ η χωρική δομή και η μουσική δομή είναι το ίδιο πράγμα.

Η μονοφωνική βυζαντινή μελωδία εκτελείται από τον πρωτοψάλτη. Κάτω από αυτήν κρατιέται το ίσον — μια συνεχής, ακίνητη βάση στον βασικό φθόγγο του ήχου. Το ίσον όμως δεν το κρατά ένα πρόσωπο: το κρατούν οι ισοκράτες, μια ομάδα που στέκεται πίσω και γύρω από τον πρωτοψάλτη, στο αναλόγιο. Η ακουστική συνέπεια είναι ρητή και μετρήσιμη:

• ο πρωτοψάλτης είναι σημειακή πηγή: ένα στόμα, μία θέση, καθαρή εντόπιση·
• το ίσον είναι χωρικά κατανεμημένη πηγή: πέντε ή οκτώ φωνές σε τόξο, ελαφρώς ασύγχρονες, με μικροδιαφορές στο ύψος του τόνου, που η ακοή τις συγχωνεύει σε έναν φαρδύ, μη εντοπίσιμο όγκο.

Οι δύο ρόλοι είναι διακριτοί και μουσικά και χωρικά, και η μουσική διάκριση εξαρτάται από τη χωρική. Αν συμπτύξεις τα δύο σε στερεοφωνικό, ο πρωτοψάλτης και το ίσον καταλαμβάνουν το ίδιο πλάτος. Το ίσον παύει να είναι υπόβαθρο και γίνεται δεύτερη φωνή που ανταγωνίζεται τη μελωδία στην ίδια περιοχή του πεδίου. Ο ακροατής χάνει ακριβώς αυτό που κάνει το είδος να λειτουργεί: το ότι η μελωδία πατάει πάνω σε κάτι που την περιβάλλει χωρίς να τη διεκδικεί. Δεν πρόκειται για απώλεια «εντυπωσιασμού» — πρόκειται για απώλεια πληροφορίας.

Πώς το γράφει κανείς σε ADM. Η κατανομή ρόλων γίνεται κατευθείαν κατανομή τύπων:

• Πρωτοψάλτης → Objects (typeLabel 0003), σημειακό αντικείμενο. Ένα audioObject με ένα audioPackFormat ενός καναλιού, audioBlockFormat με σταθερό azimuth/elevation και μηδενικό ή ελάχιστο μέγεθος. Αν ο ψάλτης μετακινείται (π.χ. κατεβαίνει από το αναλόγιο για το Χερουβικό), αυτό γίνεται ακολουθία block με rtime και duration — όχι αυτοματισμός panning, αλλά καταγεγραμμένη τροχιά.
• Ισοκράτες → είτε ένα ευρύ αντικείμενο είτε ένα bed. Ως ευρύ αντικείμενο: ένα Objects pack με ρητά ορισμένα width, depth και height στο audioBlockFormat, ώστε ο renderer να το απλώσει σε πολλά ηχεία αντί να το καρφώσει σε ένα. Ως bed: ένα DirectSpeakers pack (typeLabel 0001) που κρατά τη λήψη του αναλογίου σε σταθερές θέσεις ηχείων. Το πρώτο είναι μεταφέρσιμο σε άγνωστη διάταξη· το δεύτερο είναι προβλέψιμο και ελέγξιμο. Και τα δύο είναι σωστά· η επιλογή είναι ζήτημα του τι υπόσχεσαι στον παραλήπτη.

Το κρίσιμο σημείο είναι ότι το ίσον πρέπει να είναι φαρδύ και ο πρωτοψάλτης πρέπει να είναι στενός, και ότι αυτή η διαφορά πλάτους είναι το ίδιο το περιεχόμενο. Ένα object-based master το κρατά αυτό σε κάθε διάταξη, επειδή το πλάτος δηλώνεται ως ιδιότητα και όχι ως εκχώρηση σε ηχεία.

1.1 Δεξιός και αριστερός χορός

Η ελληνική ενορία προσθέτει έναν δεύτερο, εξίσου χωρικό μηχανισμό: την αντιφωνία. Ο δεξιός χορός και ο αριστερός χορός στέκονται σε δύο αναλόγια, στις δύο πλευρές του ναού, και απαντούν ο ένας στον άλλον — στίχο προς στίχο στους αναβαθμούς, τροπάριο προς τροπάριο στους κανόνες. Η εναλλαγή δεν είναι διακοσμητική: είναι η φόρμα.

Σε δίαυλο δύο καναλιών, η αντιφωνία εκφυλίζεται σε «λίγο αριστερά / λίγο δεξιά», με τους δύο χορούς να μοιράζονται το ίδιο μέτωπο μπροστά από τον ακροατή. Στην πραγματικότητα ο ακροατής στον νάρθηκα βρίσκεται ανάμεσά τους: ο ένας χορός είναι στις ~90° αριστερά και ο άλλος στις ~90° δεξιά, με τον πρωτοψάλτη μπροστά. Αυτό είναι απλώς αδύνατο να αποδοθεί σε στερεοφωνικό — και είναι τετριμμένο σε μια διάταξη 0+5+0 ή 4+5+0, όπου τα πλευρικά ηχεία υπάρχουν ακριβώς γι' αυτό. Ως ADM: δύο audioObject με αζιμούθιο περίπου −90° και +90°, ή δύο audioContent αν θέλεις να τα διαχειρίζεσαι ως ξεχωριστά συστατικά του προγράμματος.

Κανόνας που σχεδόν ποτέ δεν αστοχεί: αν η πηγή δεν κινείται και η θέση της είναι γνωστή εκ των προτέρων, είναι bed. Αν κινείται, ή αν το πλάτος και η θέση της κουβαλούν το νόημα, είναι αντικείμενο.

1.2 Ένας συγκεκριμένος χάρτης tracks

Για να μη μείνει η συζήτηση αφηρημένη, να πώς μοιάζει ένα ρεαλιστικό παραδοτέο δεκαέξι tracks για αγρυπνία σε ενοριακό ναό, σε 4+7+0:

Δεκαέξι tracks, δώδεκα από τα οποία είναι κανάλια σταθερής θέσης και τέσσερα αντικείμενα. Το chna έχει δεκαέξι εγγραφές — εκτός αν κάποιο track αλλάζει ορισμό στη διάρκεια, οπότε έχει περισσότερες, και αυτό είναι σωστό (βλ. §6.3). Το fmt.nChannels πρέπει να λέει 16 και τίποτε άλλο.

Παρατήρησε τι κερδίζεις: το ίσον μπορεί να πλατύνει ή να στενέψει χωρίς να ξαναγράψεις ήχο, ο πρωτοψάλτης μπορεί να μετακινηθεί χωρίς αναμίξεις, και οι δύο χοροί κρατούν την αντίθεσή τους σε οποιαδήποτε διάταξη, από 0+5+0 μέχρι 9+10+3. Καμία από αυτές τις ιδιότητες δεν επιβιώνει σε στερεοφωνικό αρχείο.

2. Ο τρούλος: από πού έρχεται η πληροφορία ύψους

Στα περισσότερα είδη, το επίπεδο ύψους είναι εφέ: το ενεργοποιείς επειδή υπάρχει. Στον βυζαντινό ναό το επίπεδο ύψους έχει φυσικό αίτιο, και το αίτιο έχει όνομα — ο τρούλος.

Ο σταυροειδής εγγεγραμμένος ναός στεγάζει το κέντρο του με ημισφαιρικό τρούλο πάνω σε λοφία. Ένα ημισφαίριο είναι εστιακή γεωμετρία: συγκεντρώνει τις ανακλάσεις αντί να τις διαχέει. Ο ψάλτης στέκεται κάτω από αυτό και οι ανακλάσεις επιστρέφουν από πάνω, με καθυστέρηση που ακούγεται και δεν χρειάζεται όργανο για να επιβεβαιωθεί. Η φωνή του Παντοκράτορα — για να το πούμε όπως το λένε οι ψάλτες — δεν είναι μεταφορά· είναι η περιγραφή μιας πραγματικής διαδρομής ήχου.

Αυτό δίνει στο πάνω επίπεδο μιας διάταξης BS.2051 δικαιολογία που δεν χρειάζεται υπεράσπιση. Αν αφαιρέσεις το πάνω επίπεδο, δεν χάνεις «ατμόσφαιρα»: παύεις να έχεις ηχογράφηση αυτού του ναού και έχεις ηχογράφηση μιας χορωδίας. Και αντιστρόφως, σου δίνει δωρεάν κριτήριο ελέγχου: αν το πάνω επίπεδο είναι ψηφιακά σιωπηλό σε μια ναϊκή ηχογράφηση, το bounce είναι λάθος με πιθανότητα κοντά στη μονάδα. Υλικό του οποίου το πάνω επίπεδο οφείλει να είναι γεμάτο είναι το καλύτερο υλικό δοκιμής που μπορεί να βρει κανείς.

3. Το αρχαίο θέατρο: ο αντίθετος χώρος

Αν ο ναός είναι η περίπτωση όπου το ύψος έρχεται από πάνω, το αρχαίο θέατρο είναι η περίπτωση όπου δεν έρχεται καθόλου — και γι' αυτό είναι το δεύτερο, εξίσου ελληνικό, διδακτικό παράδειγμα.

Ένα υπαίθριο αρχαίο θέατρο δεν έχει οροφή. Δεν υπάρχει επιφάνεια πάνω από τον ακροατή για να ανακλάσει. Ό,τι φτάνει από ψηλά είναι ουρανός: αέρας, τζιτζίκια, κάποιο αεροπλάνο, η ίδια η απουσία. Ταυτόχρονα, η φημισμένη αποδοτικότητα του χώρου προέρχεται από τη λαξευμένη πέτρινη κλιμακωτή γεωμετρία του κοίλου: οι σειρές των εδωλίων λειτουργούν ως σκληρές, κεκλιμένες ανακλαστικές επιφάνειες, και ο ακροατής που κάθεται ψηλά δέχεται ενέργεια πλευρικά και από κάτω, από την ορχήστρα και από τα καθίσματα μπροστά και χαμηλότερα από αυτόν.

Αυτό είναι το ακριβώς αντίθετο προφίλ από μια αίθουσα συναυλιών, όπου το ταβάνι και οι ανακλαστήρες στέλνουν πρώιμες ανακλάσεις από πάνω. Πρακτικά:

• Το πάνω επίπεδο (τα κανάλια U) δεν πρέπει να γεμίσει με reverb «γιατί έτσι». Κουβαλά ουρανό και κοινό, δηλαδή διάχυτο περιβάλλοντα ήχο και τη μάζα των θεατών — και σε ένα γεμάτο αρχαίο θέατρο η μάζα αυτή είναι κυριολεκτικά η μεγαλύτερη πηγή του χώρου όταν χειροκροτεί.
• Οι σημαντικές ανακλάσεις είναι πλευρικές και χαμηλές. Σε διατάξεις BS.2051 που διαθέτουν κάτω επίπεδο — το σύστημα H, δηλαδή 9+10+3, το γνωστό 22.2 — αυτό είναι κάτι που μπορείς να αποδώσεις κυριολεκτικά, με τρία κάτω κανάλια. Στα συνηθισμένα 4+5+0 και 4+7+0 δεν υπάρχει κάτω επίπεδο, οπότε η πληροφορία «από κάτω» πρέπει να μεταφερθεί στο μεσαίο επίπεδο και να δηλωθεί ρητά στις σημειώσεις παράδοσης, αλλιώς κάποιος θα την «διορθώσει» ανεβάζοντάς την.
• Η στεγνότητα είναι χαρακτηριστικό, όχι ελάττωμα. Ο χρόνος αντήχησης σε υπαίθριο θέατρο είναι μικρός· αν το master σου ακούγεται σαν ναός, δεν ηχογράφησες θέατρο.

Πότε αξίζει το scene-based. Το αρχαίο θέατρο είναι από τους λίγους χώρους όπου η καταγραφή του πεδίου είναι πιο έντιμη από την καταγραφή των πηγών: το κοινό δεν είναι απαριθμήσιμο, ο άνεμος δεν έχει θέση, και το σημαντικότερο «όργανο» είναι η ίδια η γεωμετρία. Ένα μικρόφωνο Ambisonics υψηλής τάξης στο κέντρο της ορχήστρας ή στη μέση του κοίλου καταγράφει το πεδίο, και το πεδίο μπορεί μετά να ξεδιπλωθεί σε οποιαδήποτε διάταξη BS.2051 — ακόμη και σε διάταξη που δεν υπήρχε στη λήψη. Το κόστος είναι κανάλια: για τάξη N οι συνιστώσες είναι ακριβώς (N+1)². Πρώτη τάξη = 4 κανάλια, δεύτερη = 9, τρίτη = 16, τέταρτη = 25. Η διαφορά είναι αισθητή: η πρώτη τάξη δίνει σταθερό όγκο και εντελώς θολή εντόπιση — ο υποκριτής παύει να είναι σημείο και γίνεται «κάπου αριστερά»· η τρίτη τάξη τον εντοπίζει αρκετά ώστε να ακούγεται η στροφή του κεφαλιού του. Δώδεκα κανάλια παραπάνω, και τετραπλάσια κατανάλωση δίσκου.

Το ίδιο το γεγονός ότι δύο ελληνικοί χώροι απαιτούν αντίθετη μεταχείριση του ίδιου επιπέδου ηχείων είναι ο λόγος για τον οποίο η καθηλωτική μίξη δεν έχει προεπιλογή.

4. Το πανηγύρι: ο ακροατής μέσα στο γεγονός

Η τρίτη ελληνική περίπτωση δεν είναι χώρος αλλά κατάσταση. Στο πανηγύρι, η κομπανία παίζει στο ύπαιθρο — κλαρίνο, λαούτο, βιολί, νταούλι, συχνά και σαντούρι — και οι χορευτές σχηματίζουν κύκλο γύρω από τους οργανοπαίκτες, κινούμενοι δεξιόστροφα ώρες ολόκληρες. Ο ακροατής δεν βρίσκεται απέναντι από τη σκηνή· βρίσκεται μέσα στο γεγονός, με τη μουσική στο ένα σημείο και τον χορό σε περιφορά γύρω του.

Η μίξη γράφεται σχεδόν μόνη της:

• Κλαρίνο: το σόλο όργανο, σημειακό αντικείμενο, μπροστά και ελαφρώς εκτός κέντρου. Είναι το πιο εκτεθειμένο στοιχείο και το πιο ευαίσθητο σε κακή εντόπιση.
• Λαούτο και βιολί: σημειακά αντικείμενα εκατέρωθεν, με μικρό πλάτος.
• Νταούλι: σημειακό αντικείμενο με σημαντική χαμηλή ενέργεια. Προσοχή στην κατανομή προς LFE, γιατί ο ίδιος ήχος με διαφορετική διαχείριση μπάσου αλλάζει εντελώς χαρακτήρα από διάταξη σε διάταξη.
• Χορευτές — τα βήματα, τα «όπα», τα κουδούνια, τα χειροκροτήματα: αυτό είναι διάχυτο αντικείμενο μεγάλου πλάτους ή, ακόμα καλύτερα, ζωντανό bed που καταγράφηκε με πολυκάναλη λήψη στο κέντρο του κύκλου. Οι φωνές του κόσμου δεν χρειάζονται εντόπιση· χρειάζονται περιβολή.
• Πάνω επίπεδο: νυχτερινός ουρανός, καμία στέγη, τεντόπανο ή δέντρα. Λίγο και ειλικρινές.

Είναι επίσης η περίπτωση όπου το ερώτημα «αντικείμενο ή bed;» απαντιέται από τη διάρκεια και όχι από την αισθητική. Ένα πανηγύρι παίζεται συνεχόμενα, χωρίς διακοπή, και αυτό μας φέρνει στο επόμενο θέμα: το μέγεθος του αρχείου.

5. BW64: γιατί υπάρχει, με τους αριθμούς

Το κλασικό WAV είναι αρχείο RIFF. Το RIFF, από το 1991, προτάσσει σε κάθε chunk ένα πεδίο μεγέθους των 32 bit. Τα 32 bit διευθυνσιοδοτούν 4.294.967.296 bytes — 4 GiB — και αυτό είναι απόλυτο ταβάνι τόσο για το αρχείο συνολικά όσο και για το chunk data μέσα του.

Ας το κάνουμε αριθμούς. Ο ρυθμός δεδομένων ασυμπίεστου PCM είναι:

κανάλια × (bit ανά δείγμα ÷ 8) × συχνότητα δειγματοληψίας = bytes ανά δευτερόλεπτο

Στερεοφωνικό, 48 kHz / 24 bit. 2 × 3 × 48.000 = 288.000 bytes/s. Διαιρώντας: 4.294.967.296 ÷ 288.000 = 14.913 δευτερόλεπτα, δηλαδή 4 ώρες 8 λεπτά 33 δευτερόλεπτα. Το όριο είναι θεωρητικό.

Παραδοτέο πανηγυριού, 16 tracks (bed 7.1.4 συν τέσσερα αντικείμενα), 96 kHz / 24 bit. 16 × 3 × 96.000 = 4.608.000 bytes/s. 4.294.967.296 ÷ 4.608.000 = 932 δευτερόλεπτα, δηλαδή 15 λεπτά 32 δευτερόλεπτα. Ένα πανηγύρι διαρκεί έξι ώρες.

Ναϊκή ηχογράφηση, 24 tracks, 48 kHz / 24 bit. 24 × 3 × 48.000 = 3.456.000 bytes/s. 4.294.967.296 ÷ 3.456.000 = 1.242,8 δευτερόλεπτα = 20 λεπτά 43 δευτερόλεπτα. Μια αγρυπνία διαρκεί πέντε ώρες: 3.456.000 × 18.000 = 62.208.000.000 bytes, δηλαδή περίπου 14,5 φορές το όριο του RIFF.

Πυκνό object-based master, 128 tracks, 96 kHz / 24 bit. 128 × 3 × 96.000 = 36.864.000 bytes/s. Το όριο έρχεται στα 116,5 δευτερόλεπτα — κάτω από δύο λεπτά.

Ένας εγγραφέας WAV που χτυπά αυτό το όριο παράγει είτε κομμένο αρχείο είτε αρχείο του οποίου τα δηλωμένα μεγέθη έχουν αθόρυβα υπερχειλίσει.

Το EBU αντιμετώπισε πρώτο το πρόβλημα με το RF64 (EBU Tech 3306). Η ITU το προχώρησε ως Σύσταση ITU-R BS.2088, Long-form file format for the international exchange of audio programme materials with metadata — το BW64. Η BS.2088 είναι ρητή ως προς τον μηχανισμό: «The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file» (τα τέσσερα πρώτα bytes γράφουν BW64 αντί για RIFF), και τα παλιά πεδία των 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 που οφείλει να βρίσκεται πρώτο μέσα στο αρχείο.

Είναι χρήσιμο να το δει κανείς ως τρίτη γενιά μιας γραμμής: RIFF/WAVE έδωσε τον περιέκτη με chunks· το Broadcast Wave (BWF, EBU Tech 3285) πρόσθεσε το chunk bext με προέλευση, timecode και ιστορικό κωδικοποίησης· το BW64 τα κρατά όλα, προσθέτει διευθυνσιοδότηση 64 bit και τα chunks που μεταφέρουν το ADM.

6. Η διάταξη των chunks, συγκεκριμένα

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

6.1 ds64 — ο πίνακας μεγεθών 64 bit

Πρέπει να είναι το πρώτο chunk μετά την υπογραφή BW64, γιατί ο αναγνώστης πρέπει να ξέρει τα πραγματικά μεγέθη πριν διασχίσει οτιδήποτε άλλο. Τα πεδία του είναι ζεύγη 32 bit που συνθέτουν ποσότητες 64 bit:

Η αριθμητική: 8 bytes κεφαλίδα (ckID + ckSize) συν 8 + 8 + 8 + 4 = 28 bytes σώματος, άρα 36 bytes συνολικά όταν ο πίνακας είναι κενός. Κάθε εγγραφή ChunkSize64 προσθέτει 4 bytes αναγνωριστικού chunk συν 4 + 4 bytes μεγέθους = 12 bytes.

Ο table[] μετράει περισσότερο απ' όσο φαίνεται. Ένα axml που περιγράφει χιλιάδες αντικείμενα με αυτοματισμό ακριβείας δείγματος μπορεί να πλησιάσει ή να ξεπεράσει τα 4 GB· ο πίνακας είναι ο μοναδικός τρόπος να δηλώσει μέγεθος 64 bit οποιοδήποτε chunk εκτός του data.

6.2 fmt — η περιγραφή της ουσίας

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

6.3 chna — ο πίνακας αντιστοίχισης καναλιών

Το chna είναι η γέφυρα ανάμεσα στα φυσικά tracks και στο ADM. Ξεκινά με:

• ckID — 4 bytes, 'chna'
• ckSize — 4 bytes
• numTracks — 2 bytes, πλήθος tracks στο αρχείο
• numUIDs — 2 bytes, πλήθος εγγραφών audioTrackUID που ακολουθούν

Ακολουθεί επίπεδος πίνακας εγγραφών audioID σταθερού πλάτους. Κάθε εγγραφή είναι ακριβώς 40 bytes:

2 + 12 + 14 + 11 + 1 = 40. Ας ελεγχθεί και με τα ίδια τα παραδείγματα: ATU_00000001 έχει 12 χαρακτήρες· AT_00031001_01 έχει 14· AP_00031001 έχει 11. Τα πλάτη δεν είναι συμβουλευτικά — είναι σταθερού μήκους ASCII, και ένας εγγραφέας που παράγει UID δεκατριών χαρακτήρων δεν έχει φτιάξει «λίγο ασυνήθιστο» πίνακα, έχει φτιάξει κατεστραμμένο πίνακα: όλα τα επόμενα πεδία μετατοπίζονται κατά ένα byte και ο αναγνώστης διαβάζει σκουπίδια από εκεί και πέρα.

Το μέγεθος του chunk προκύπτει αμέσως. Για το παραδοτέο πανηγυριού των 16 tracks με ένα UID ανά track: 4 bytes (numTracks + numUIDs) + 16 × 40 = 644 bytes σώματος, συν 8 bytes κεφαλίδας = 652 bytes, ζυγός αριθμός, χωρίς ανάγκη επιπλέον γεμίσματος. Για ένα master 128 tracks: 4 + 128 × 40 = 5.124 συν 8 = 5.132 bytes. Το chna είναι μικροσκοπικό — και ακριβώς γι' αυτό δεν υπάρχει καμία δικαιολογία να μην ελεγχθεί byte προς byte.

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

Το track UID είναι ο σειριακός αριθμός της ταυτότητας ενός φυσικού track, και υπάρχει ακριβώς για να μπορεί ένα track να αλλάξει νόμιμα περιεχόμενο στη μέση ενός προγράμματος.

Αυτός είναι ο λόγος που το 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 επιτρέπεται λοιπόν να εμφανίζεται σε πολλές εγγραφές. Παράδειγμα ακριβώς από το υλικό μας: στην αγρυπνία, το track 14 κρατά στο πρώτο μέρος το ευρύ αντικείμενο «ίσον» και αργότερα, στο δοξαστικό, γίνεται δεύτερο σημειακό αντικείμενο «λαμπαδάριος». Δύο UID, ένα trackIndex, απολύτως έγκυρο. Εργαλεία ελέγχου που υποθέτουν ένα UID ανά track σημαδεύουν σωστά αρχεία ως χαλασμένα.

6.4 axml — το ίδιο το ADM

Έγγραφο XML σε UTF-8 που περιέχει το δέντρο <audioFormatExtended>. Είναι κείμενο, είναι αναγνώσιμο, και εκεί ζουν ουσιαστικά όλες οι ενδιαφέρουσες αστοχίες.

6.5 data — το διαπλεγμένο PCM

Απλά διαπλεγμένα δείγματα, όπως ακριβώς στο WAV. Τίποτα μέσα στο data δεν γνωρίζει τίποτα για αντικείμενα.

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

7. Ελληνικοί χαρακτήρες: επιτρεπτοί στο axml, ποτέ στο chna

Εδώ υπάρχει μια παγίδα που αφορά ειδικά τα ελληνικά και που παράγει αρχεία τα οποία «άνοιγαν κανονικά» μέχρι που δεν άνοιξαν.

Στο axml τα ελληνικά είναι απολύτως εντάξει. Το chunk είναι XML σε UTF-8, και ένα audioProgrammeName="Ἀκολουθία τοῦ Ὄρθρου" ή audioObjectName="Κλαρίνο" είναι έγκυρο, σωστό και προτιμότερο από μεταγραφή σε λατινικούς χαρακτήρες. Γράψε τα ονόματα στα ελληνικά.

Στο chna τα ελληνικά είναι απαγορευμένα, και ο λόγος είναι αριθμητικός. Τα πεδία UID, trackRef και packRef είναι σταθερού πλάτους σε bytes, όχι σε χαρακτήρες, και το περιεχόμενό τους είναι ASCII αναγνωριστικά της μορφής ATU_, AT_, AP_ συν δεκαεξαδικά ψηφία. Ένα ελληνικό γράμμα στο μονοτονικό εύρος (U+0386–U+03CE: Α, κ, ά) κωδικοποιείται σε 2 bytes σε UTF-8. Ένα πολυτονικό γράμμα από την περιοχή Greek Extended (U+1F00–U+1FFF: ᾳ, ἡ, ῶ) κωδικοποιείται σε 3 bytes.

Δούλεψε την αριθμητική στο πεδίο UID των 12 bytes:

• ATU_00000001 — 12 χαρακτήρες ASCII = 12 bytes. Γεμίζει το πεδίο ακριβώς. Σωστό.
• ΙΣΟΝ01 — 6 ελληνικοί χαρακτήρες × 2 bytes = 12 bytes. Γεμίζει το πεδίο ακριβώς και περνά κάθε έλεγχο μήκους που μετράει bytes. Δεν είναι όμως έγκυρο audioTrackUID, γιατί δεν έχει το πρόθεμα ATU_ και δεν μπορεί να αντιστοιχιστεί σε τίποτα μέσα στο XML. Αυτή είναι η επικίνδυνη περίπτωση: λάθος που δεν φαίνεται σαν λάθος.
• ΚΛΑΡΙΝΟ — 7 ελληνικοί χαρακτήρες × 2 bytes = 14 bytes. Δύο bytes περισσότερα από το πεδίο. Αν ο εγγραφέας δεν κόψει, τα δύο πλεονάζοντα bytes εισβάλλουν στην αρχή του trackRef, όλη η εγγραφή μετατοπίζεται και ο πίνακας από εκείνο το σημείο και μετά είναι άχρηστος. Αν ο εγγραφέας κόψει στα 12 bytes, κόβει στη μέση της ακολουθίας UTF-8 του έβδομου γράμματος και αφήνει μισό χαρακτήρα — ένα byte που κανένας αποκωδικοποιητής δεν μπορεί να ερμηνεύσει.
• ᾨΔΗ — ένας πολυτονικός χαρακτήρας (3 bytes) συν τρεις μονοτονικοί (2 bytes ο καθένας) = 3 + 6 = 9 bytes για 4 μόνο γράμματα. Το ότι «χώρεσε» δεν σημαίνει τίποτα· απλώς κάνει την αστοχία λιγότερο εμφανή.

Και μια δεύτερη, παλαιότερη παγίδα που εξακολουθεί να εμφανίζεται σε ελληνικά studio: εργαλεία που γράφουν ελληνικά σε Windows-1253 αντί για UTF-8. Στο 1253 κάθε ελληνικό γράμμα είναι 1 byte, οπότε το ΚΛΑΡΙΝΟ γίνεται 7 bytes και «χωράει». Το αποτέλεσμα είναι αρχείο που φαίνεται δομικά σωστό, με ονόματα που εμφανίζονται ως μουτζούρες σε κάθε αναγνώστη UTF-8 και με πίνακα chna που περιέχει σκουπίδια εκεί που περίμενε αναγνωριστικά.

Κανόνας: τα ελληνικά ανήκουν στα ονόματα, όχι στα αναγνωριστικά. Τα πεδία του chna είναι μηχανικά κλειδιά σταθερού πλάτους — κράτα τα ASCII, κράτα τα στη μορφή που ορίζει η BS.2076, και βάλε το «Κλαρίνο» στο audioObjectName όπου ανήκει.

8. Το μοντέλο αντικειμένων του ADM

Η ITU-R BS.2076 χωρίζει το μοντέλο στα δύο. Το μέρος μορφής (format part) «describes the technical nature of the audio so it can be decoded or rendered correctly» και μπορεί να συνταχθεί πριν καν υπάρξει ήχος. Το μέρος περιεχομένου (content part) περιγράφει «the language of dialogue, the loudness, etc.» και ολοκληρώνεται μόνο όταν υπάρχουν σήματα. Το να ξέρεις σε ποιο μισό ανήκει ένα στοιχείο σου λέει σε ποιο στάδιο της παραγωγής μπήκε το σφάλμα.

Η ιεραρχία, από πάνω προς τα κάτω:

• audioProgramme — μία ολοκληρωμένη παρουσίαση. Στην αγρυπνία μας: «Ἀκολουθία, ελληνικά, 4+7+0».
• audioContent — συστατικό με συντακτικό νόημα: ο δεξιός χορός, ο αριστερός χορός, το αναλόγιο, ο περιβάλλων ήχος του ναού.
• audioObject — η άρθρωση ανάμεσα στην πρόθεση και την τεχνική μορφή. Κουβαλά χρόνο έναρξης και διάρκεια, και αναφέρεται σε μηδέν ή περισσότερα audioPackFormat, σε φωλιασμένα audioObject και σε audioTrackUID. Εδώ το περιεχόμενο συναντά την ουσία.
• audioPackFormat — ομάδα καναλιών που ανήκουν μαζί: ένα bed 7.1.4, ένα στερεοφωνικό ζεύγος, ένα σύνολο HOA δεδομένης τάξης.
• audioChannelFormat — η συμπεριφορά ενός καναλιού στον χρόνο. Περιέχει ένα ή περισσότερα audioBlockFormat.
• audioBlockFormat — το άτομο. Για Objects: θέση (azimuth/elevation/distance ή καρτεσιανά X/Y/Z), gain, μέγεθος, διάχυση, καθώς και rtime και duration. Στατικό αντικείμενο = ένα block· κινούμενο = ακολουθία.
• audioTrackUID — το φύλλο, και το μοναδικό στοιχείο που αντιστοιχεί σε φυσικό track.

Τα audioStreamFormat και audioTrackFormat παρεμβάλλονται και περιγράφουν την κωδικοποίηση ροής. Η BS.2076-3 σημειώνει ότι για PCM είναι ουσιαστικά περιττά — «the audioStreamFormat and the audioTrackFormat should be omitted» — αλλά ότι οι αναγνώστες «should be aware that existing ADM files (based on Recommendation ITU-R BS.2076-2 and earlier) for PCM audio may contain» αυτά τα στοιχεία. Και οι δύο μορφές είναι νόμιμες· ένας validator που επιμένει στη μία κάνει λάθος για την άλλη.

Το ADM είναι γράφος αναφορών, όχι φωλιασμένο έγγραφο, και κάθε σοβαρή αποτυχία παράδοσης είναι μια σπασμένη ακμή αυτού του γράφου.

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

Το ίσον είναι το τέλειο παράδειγμα του γιατί αυτό απαιτεί μηχανή. Αν χαθεί το αντικείμενο του πρωτοψάλτη, θα το ακούσεις σε ένα δευτερόλεπτο. Αν χαθεί το ευρύ αντικείμενο των ισοκρατών, θα ακούσεις «κάπως πιο στεγνό, κάπως πιο ψηλό» και θα το γράψεις στο δωμάτιο. Το ανθρώπινο αυτί δεν ακούει την απουσία εκείνου για το οποίο δεν προειδοποιήθηκε.

9. Απόδοση: BS.2127 πάνω σε διατάξεις BS.2051

Η ITU-R BS.2051 τυποποιεί τις διατάξεις ηχείων ως πλήθη ανά επίπεδο, με τη μορφή Άνω + Μεσαίο + Κάτω: σύστημα A = 0+2+0 (στερεοφωνικό), B = 0+5+0 (5.1), D = 4+5+0, J = 4+7+0, H = 9+10+3 (η διάταξη 22.2).

Η ITU-R BS.2127 ορίζει τον renderer αναφοράς του ADM: τον αλγόριθμο που παίρνει το αρχείο BW64/ADM και το μετατρέπει σε σήματα για μια συγκεκριμένη διάταξη BS.2051. Το ανοικτού κώδικα αδελφό του, ο EBU ADM Renderer (EBU Tech 3388), είναι ο πρακτικός τρόπος να πάρεις αναπαράξιμο αποτέλεσμα χωρίς να εξαρτηθείς από ιδιόκτητη αλυσίδα.

Το σημείο που αξίζει να συγκρατηθεί: η απόδοση δεν είναι μία. Το ίδιο master παράγει διαφορετικά σήματα σε 0+5+0, 4+5+0, 4+7+0 και 9+10+3, και η διαφορά δεν είναι ομοιόμορφη σε όλο το υλικό. Το φαρδύ ίσον, ειδικά, αλλάζει χαρακτήρα ανάλογα με το πόσα ηχεία υπάρχουν για να το μοιραστούν: σε 0+5+0 μπορεί να ακουστεί σχεδόν σαν σημειακή πηγή, ενώ σε 4+7+0 απλώνεται όπως πρέπει. Γι' αυτό, όταν δηλώνεις οτιδήποτε για το master σου, δήλωσε τα τρία μαζί: ποιον renderer, σε ποια διάταξη, σε ποια έκδοση.

Το binaural (δυωτικό, για ακουστικά) απαντά σε κάποια ερωτήματα και σε άλλα όχι. Δεν σου λέει πώς κατανέμεται η ενέργεια στα επιμέρους άνω ηχεία, πόσο μπάσο καταλήγει στο LFE, ή πώς αλλάζει το χρώμα του χορού μεταξύ 4+5+0 και 4+7+0. Η ατομική διαφορά των συναρτήσεων μεταφοράς κεφαλής είναι μεγάλη· η ανύψωση σε ακουστικά αλλού ακούγεται «πάνω» και αλλού «πίσω».

10. Μέτρηση έντασης καθηλωτικού υλικού

Εδώ χρειάζεται αυστηρός διαχωρισμός ανάμεσα σε αυτό που είναι δημοσιευμένο και σε αυτό που κυκλοφορεί.

Τι ορίζει η ITU-R BS.1770. Σε ισχύ είναι η BS.1770-5 (Νοέμβριος 2023)· η BS.1770-4 (Οκτώβριος 2015) έχει αντικατασταθεί, παρότι είναι η έκδοση που εξακολουθούν να αναφέρουν τα περισσότερα εγκατεστημένα μετρητικά. Ονόμαζε πάντα την -5 ως τρέχουσα.

Ο αλγόριθμος:

• Στάθμιση K: φίλτρο δύο σταδίων — ένα high-shelf («head» filter, μοντέλο άκαμπτης σφαίρας) και έπειτα ένα high-pass (RLB). Η ενίσχυση της καμπύλης K στο 1 kHz είναι +0,698 dB (γραμμικά 1,0836).
• Blocks 400 ms με επικάλυψη 75 %.
• Απόλυτη πύλη: απορρίπτονται τα blocks κάτω από −70 LUFS.
• Σχετική πύλη: υπολογίζεται από τον μέσο όρο των blocks που επέζησαν της απόλυτης πύλης, με μετατόπιση −10 LU. Δεν είναι ο μέσος όρος χωρίς πύλη. Η διάκριση αυτή δηλώνεται λανθασμένα πολύ συχνά.
• Loudness Range (LRA), EBU Tech 3342, χρησιμοποιεί σχετική πύλη −20 LU — όχι −10 LU. Το −10 στο LRA είναι κλασικό σφάλμα υλοποίησης.
• Short-term: παράθυρο 3 s. Momentary: 400 ms (EBU Tech 3341).
• True peak: μετριέται σε υπερδειγματοληπτημένο σήμα (τουλάχιστον 4×· το 8× είναι καλύτερο). Το sample peak δεν είναι true peak, και οι κορυφές ανάμεσα στα δείγματα μπορούν να ξεπεράσουν τη μεγαλύτερη τιμή δείγματος.

Οι συντελεστές καναλιών στον βασικό αλγόριθμο είναι 1,0 (0 dB) για L, R και C, και 1,41 (≈ +1,5 dB) για Ls και Rs, με το LFE εξαιρούμενο. Ο βασικός αλγόριθμος καλύπτει «from one to five channels». Η BS.1770-5 επεκτείνεται πέρα από αυτό στα παραρτήματά της, καλύπτοντας τα προηγμένα συστήματα της BS.2051 — αυθαίρετες θέσεις ηχείων και κανάλια ύψους — καθώς και object-based ήχο, ο οποίος πρέπει πρώτα να αποδοθεί για να μετρηθεί.

Η ένταση καθηλωτικού υλικού δεν είναι ιδιότητα του αρχείου· είναι ιδιότητα μιας απόδοσης. Άλλαξε τη διάταξη-στόχο και αλλάζει ο αριθμός.

Ένα στερεοφωνικό master έχει μία τιμή έντασης. Ένα object-based master έχει τόσες όσες και οι διατάξεις-στόχοι, και ο μόνος έντιμος τρόπος να αναφέρεις μία είναι να ονομάσεις μαζί τη διάταξη και τον renderer.

Τι είναι δημοσιευμένο για μουσική. Για στερεοφωνικό, το Spotify δημοσιεύει στόχο ολοκληρωμένης έντασης −14 LUFS και όριο true peak −1 dBTP, που σφίγγει στα −2 dBTP για master πιο δυνατά από −14 LUFS. Το AES TD1008 συνιστά −16 LUFS για μουσική· η τιμή −18 LUFS του ίδιου κειμένου αφορά υλικό με κυρίαρχο τον λόγο (ειδήσεις, εκπομπές λόγου, δραματοποιημένο υλικό), και το να δηλώνεται το −18 ως στόχος για μουσική είναι συχνό και σοβαρό σφάλμα. Το EBU R 128 ορίζει −23 LUFS, αλλά είναι πρακτική ραδιοτηλεοπτικής κανονικοποίησης, όχι προδιαγραφή streaming μουσικής.

Τι δεν είναι δημοσιευμένο. Καμία υπηρεσία streaming μουσικής δεν δημοσιεύει στόχο ολοκληρωμένης έντασης για καθηλωτική παράδοση. Κυκλοφορούν αριθμοί σε φόρουμ και σε υλικό εκπαίδευσης προμηθευτών· κάποιοι είναι εύλογοι και κάποιοι μάλλον σωστοί, αλλά κανένας δεν είναι δημοσιευμένη προδιαγραφή. Ομοίως, τα Apple Music, YouTube Music, Amazon Music, TIDAL και Deezer δεν δημοσιεύουν στόχο κανονικοποίησης ούτε καν για στερεοφωνικό: οι τιμές που αναφέρονται ευρέως γι' αυτά (Apple ≈ −16, YouTube Music ≈ −14, Amazon ≈ −14, TIDAL ≈ −14, Deezer ≈ −15) είναι ευρέως αναφερόμενες αλλά μη δημοσιευμένες από την υπηρεσία, και δεν επιτρέπεται να υπολογίσεις μεταβολή στάθμης από αυτές.

Χρήσιμο να ειπωθεί και το θετικό: η κανονικοποίηση γίνεται στην αναπαραγωγή, και master πιο δυνατό από τον στόχο χαμηλώνει κατά τη διαφορά. Η ανοδική κανονικοποίηση υπάρχει αλλά είναι υπό όρους — το Spotify αναφέρει ότι «Positive gain is applied to softer masters so the loudness level is -14 dB LUFS» και ταυτόχρονα ότι «We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality». Άρα ένα ήσυχο master με ψηλές κορυφές μπορεί να μην ανέβει μέχρι τον στόχο. Το συμπέρασμα: η υπερβολική συμπίεση αγοράζει επιπεδότητα, όχι ένταση.

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

11. Η ειλικρινής πρακτική θέση για τα ελληνικά studio

Ας το πούμε καθαρά, γιατί η αποσιώπησή του κάνει κακό: η καθηλωτική παρακολούθηση (immersive monitoring) είναι σπάνια στα ελληνικά μουσικά studio. Ελάχιστοι χώροι έχουν βαθμονομημένη διάταξη 4+7+0. Οι περισσότεροι από εμάς θα δουλέψουμε με στερεοφωνικά ηχεία, ακουστικά και ένα binaural render.

Αυτό δεν σημαίνει ότι δεν έχεις τι να κάνεις. Σημαίνει ότι η αξία σου μετατοπίζεται:

1. Σωστή παράδοση. Το αρχείο να είναι BW64, όχι μετονομασμένο WAV. Ο ρυθμός δειγματοληψίας και το βάθος bit να είναι ακριβώς αυτά που ζητά η προδιαγραφή. Χωρίς μετατροπή ρυθμού δειγματοληψίας μετά τη σύνταξη του ADM — κάθε rtime και duration εκφρασμένο σε δείγματα ακυρώνεται.
2. Σωστά μεταδεδομένα. Ονόματα στα ελληνικά μέσα στο axml, αναγνωριστικά σε ASCII μέσα στο chna, κάθε αναφορά να επιλύεται, κάθε block να είναι συνεχές και μονότονο στον χρόνο.
3. Επαλήθευση αρχείου που δεν μπορείς να ακούσεις σωστά. Αυτό είναι το σημαντικότερο. Μπορείς να αποδείξεις με μηχανή ότι το fmt.nChannels ισούται με το chna.numTracks, ότι κάθε trackIndex είναι εντός εύρους, ότι κανένα UID δεν είναι ορφανό, ότι το πάνω επίπεδο δεν είναι ψηφιακή σιωπή, ότι το axml υπάρχει ακόμη κι αν βρίσκεται μετά το data. Καμία από αυτές τις αποδείξεις δεν απαιτεί δωμάτιο με δώδεκα ηχεία.

Ένας δωρεάν επιθεωρητής BW64/ADM που τρέχει στον περιηγητή διατίθεται στο mazufa.com: αναλύει τον περιέκτη και τα μεταδεδομένα εξ ολοκλήρου στη δική σου συσκευή και δεν ανεβάζει τίποτα, κάτι που τον κάνει χρησιμοποιήσιμο σε υλικό που συμβατικά δεν επιτρέπεται να φύγει από τον χώρο.

Και μια νηφάλια σημείωση: αν δεν έχεις πού να ακούσεις, μην υπόσχεσαι καλλιτεχνική καθηλωτική μίξη. Υποσχέσου τεχνικά ορθό παραδοτέο, δηλωμένη διάταξη, δηλωμένο renderer, μετρημένη ένταση και καθαρές σημειώσεις παράδοσης. Αυτό είναι έντιμο και είναι και ό,τι κόβεται πιο συχνά στον έλεγχο.

12. Λίστα ελέγχου παράδοσης

Δούλεψέ την με τη σειρά. Οι δομικοί έλεγχοι πρώτοι — είναι γρήγοροι και ακυρώνουν όλα τα επόμενα.

Περιέκτης

1. Τα πρώτα τέσσερα bytes είναι BW64. Αν είναι RIFF, το αρχείο είναι απλό WAV και δεν μπορεί να ξεπεράσει τα 4 GB.
2. Το ds64 είναι το πρώτο chunk μετά την υπογραφή και τα μεγέθη 64 bit συμφωνούν με το πραγματικό μέγεθος αρχείου και data.
3. Κάθε υπερμέγεθες chunk πλην του data έχει εγγραφή ChunkSize64 στον πίνακα του ds64.
4. Εντόπισε ρητά το axml, και μετά το data. Μη βγάζεις συμπέρασμα «δεν υπάρχει ADM» από μερική σάρωση.

Ουσία

1. Ρυθμός δειγματοληψίας και βάθος bit στο fmt ταιριάζουν ακριβώς με την προδιαγραφή.
2. fmt.nChannels = chna.numTracks.
3. Κάθε trackIndex στο chna είναι εντός 1 … fmt.nChannels και αριθμημένο από το 1.

Ακεραιότητα chna

1. Κάθε εγγραφή είναι ακριβώς 40 bytes, με σωστά γεμισμένα πεδία σταθερού πλάτους.
2. Κανένας μη-ASCII χαρακτήρας σε κανένα πεδίο του chna. Έλεγξε ρητά για bytes ≥ 0x80.
3. Κάθε packRef στο εύρος 0x1000+ επιλύεται σε προσαρμοσμένο ορισμό μέσα στο axml.
4. Επαναλαμβανόμενα trackIndex είναι σκόπιμα (track που αλλάζει ορισμό), όχι διπλοεγγραφές.

Γράφος ADM

1. Κάθε audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef και audioTrackUIDRef επιλύεται. Μηδέν κρεμασμένες ακμές.
2. Κανένα ορφανό audioTrackUID προς καμία κατεύθυνση. Το EBU Tech 3392 το λέει ρητά: «If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs».
3. Καμία κυκλική ή αυτοαναφορά.
4. Το typeLabel κάθε audioChannelFormat ταιριάζει με το γονικό audioPackFormat.

Χρονισμός

1. Channel formats με πολλά blocks φέρουν και rtime και duration σε κάθε block. Η BS.2076 είναι κατηγορηματική: «When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present».
2. Τα blocks είναι συνεχή και μονότονα: rtime[n] + duration[n] == rtime[n+1]. Οι αστοχίες έρχονται σε τρεις μορφές — κενά (απροσδιόριστη συμπεριφορά renderer), επικαλύψεις και blocks εκτός χρονολογικής σειράς.
3. Τα αντικείμενα ξεκινούν στο 00:00:00.00000.

Περιεχόμενο

1. Κάθε κανάλι δηλωμένου bed περιέχει ό,τι πρέπει· διερεύνησε κάθε ψηφιακή σιωπή. Στη ναϊκή ηχογράφηση, άδειο άνω κανάλι είναι σχεδόν σίγουρα σφάλμα εξαγωγής· στην ηχογράφηση αρχαίου θεάτρου, άδειο άνω κανάλι μπορεί κάλλιστα να είναι σωστό.
2. Το πλήθος αντικειμένων και η διαμόρφωση του bed ταιριάζουν με την προδιαγραφή.
3. Το timecode έναρξης στο bext είναι σωστό και συνεπές σε όλα τα παραδοτέα του σετ.

Conforms και μετρήσεις

1. Τα στερεοφωνικά και binaural conforms παράγονται ξανά από το τρέχον master, δεν μεταφέρονται από παλιότερη έκδοση. Η συνηθισμένη αστοχία δεν είναι η απουσία — η απουσία φαίνεται — αλλά η ολίσθηση: conform που βγήκε από παλιότερη εκδοχή ή είναι μερικά frames μετατοπισμένο.
2. Διάρκειες και timecode έναρξης συμφωνούν με το master δείγμα προς δείγμα.
3. Η ένταση μετρήθηκε σε ονομασμένη απόδοση, σε ονομασμένη διάταξη, με ονομασμένο μετρητή BS.1770-5, και τα τρία καταγράφηκαν στις σημειώσεις παράδοσης.

Αναπαραγωγιμότητα

1. Checksum σε κάθε παραδοτέο, με αρχείο καταγραφής.
2. Αρχειοθέτησε τη session και το ADM XML χωριστά από το BW64. Ένα XML που μπορείς να συγκρίνεις με diff αξίζει αργότερα περισσότερο από ένα δυαδικό που μπορείς μόνο να ξαναδιαβάσεις.

Ένα καθηλωτικό παραδοτέο δεν είναι έτοιμο όταν ακούγεται σωστό· είναι έτοιμο όταν μια μηχανή που δεν το άκουσε ποτέ μπορεί να αποδείξει ότι όλες οι αναφορές του επιλύονται.

13. Κλείσιμο

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

Ειδικά για ελληνικό υλικό: κράτα τα ελληνικά στα ονόματα, κράτα τα αναγνωριστικά ASCII, και θυμήσου ότι το πάνω επίπεδο σημαίνει άλλο πράγμα κάτω από έναν τρούλο και άλλο κάτω από τον ουρανό της Επιδαύρου.

Η διανομή μέσω Mazufa είναι δωρεάν — χωρίς κόστος ανεβάσματος, χωρίς συνδρομή, χωρίς χρέωση ανά κυκλοφορία — με μοναδική κράτηση το 5% των εισπραττόμενων δικαιωμάτων, και κάθε πλήρης αίτηση περνά από ανθρώπινη αξιολόγηση.

Πηγές

Συστάσεις 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.2076-2 (10/2019), Audio definition model — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2076-2-201910-S!!TOC-HTM-E.htm
• 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
• Σελίδα σύστασης BS.2127 — https://www.itu.int/rec/R-REC-BS.2127

Τεχνικά κείμενα 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/docs/tech/tech3388.pdf και https://tech.ebu.ch/publications/tech3388
• EBU Tech 3343, Practical guidelines for production and implementation in accordance with EBU R 128 — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3343v2_0.pdf
• EBU R 128, EBU Tech 3341 (μετρητές), EBU Tech 3342 (Loudness Range) — https://tech.ebu.ch
• 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
• Τεκμηρίωση EBU ADM Renderer (EAR), BW64 I/O — https://ear.readthedocs.io/en/latest/BW64.html
• libbw64, υλοποίηση αναφοράς — https://github.com/ebu/libbw64
• libadm, υλοποίηση αναφοράς — https://github.com/ebu/libadm

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/

Unicode

• Unicode Standard, Greek and Coptic (U+0370–U+03FF) — https://www.unicode.org/charts/PDF/U0370.pdf
• Unicode Standard, Greek Extended (U+1F00–U+1FFF) — https://www.unicode.org/charts/PDF/U1F00.pdf

Τελευταίος έλεγχος: Σεπτέμβριος 2026. Τα πρότυπα αναθεωρούνται — έλεγχε πάντα τις παραπάνω σελίδες ITU και EBU για την τρέχουσα έκδοση πριν παραθέσεις αριθμό ρήτρας.