در RF64، مقدارِ۳۲بیتیِ همهٔ اندازه‌ها را نباید بی‌تفسیر طولِ واقعی بدانیم. در سرآیندِ RIFF و dataِ این قالب، مقدارِ ویژهٔ FFFFFFFF می‌تواند نشانهٔ مراجعه به اندازهٔ۶۴بیتیِ ds64 باشد. این راهنما یک RF64 بسیار کوچک و اصیل را می‌سازد و طولِ اعلامی را با بایتِ واقعی می‌سنجد؛ فایلِ چندگیگابایتی تولید نمی‌کند.
مشکلِ اندازه را از کیفیتِ صدا جدا کنیم
EBU Tech3306 نسخهٔ۱٫۱، RF64 را برای نیاز به اندازه‌های بزرگ‌تر در خانوادهٔ BWF توضیح می‌دهد. عددِ اندازه، واحدش بایت است؛ sampleCount مفهومِ دیگری دارد. بزرگ‌بودنِ ظرفیتِ ظرف نه دقتِ گفتار را بالا می‌برد، نه تضمین می‌کند هر ابزارِ WAV آن را می‌خواند. تغییرِ پسوند هم ساختارِ فایل را تبدیل نمی‌کند.
سند برای فایلِ کوچک استفاده از BWF معمولی را توصیه می‌کند؛ انتخابِ RF64ِ کوچک در این صفحه فقط برای آموزشِ خواندنِ قرارداد است. نمونهٔ ما PCM تک‌کانالهٔ۱۶بیتی با نرخ۸۰۰۰و هشت فریمِ صفر دارد. این سکوتِ ساختگی، ضبطِ انسان یا آزمایشِ سازگاریِ پخش‌کننده و اپرانگار نیست.
ds64 باید کجا باشد؟
بعد از RF64، اندازهٔ۳۲بیتیِ ویژه و شناسهٔ WAVE، chunkِ اجباریِ ds64 نخست می‌آید. در زیرمجموعهٔ ما payload آن۲۸بایت است: riffSize،dataSize وsampleCount هرکدام۶۴بیتی و سپس طولِ جدولِ اندازه‌ها. جدولِ اختیاری را صفر گرفته‌ایم و نسخهٔ غیرصفر را خارج از دامنه می‌دانیم.
سرآیندهای chunk در این فایل little-endian هستند. مقدارِ riffSize اندازهٔ فایل بدون هشت بایتِ آغازین است؛ dataSize فقط بدنهٔ داده را می‌گوید. در سرآیندِ data نیز sentinel داریم و reader اندازهٔ مؤثر را از ds64 می‌گیرد. جایگزینیِ یک عدد در نمایشِ متنی کافی نیست؛ باید مرز و طولِ واقعیِ chunkها کنترل شوند.
فایلِ کاملِ کوچک چه چیزی دارد؟
ترتیبِ نمونه RF64/WAVE،ds64،fmt،JUNKوdata است. fmtِ۱۶بایتی PCMِ اعلام‌شده را دارد؛ JUNK سه بایت دارد و برای ترازِ دوبایتی یک بایتِ پدینگ می‌گیرد. payloadِ data شانزده بایت است؛ با blockAlignِ۲،هشت فریم به دست می‌آید و با sampleCountِ۸تطبیق دارد.
| کنترل | قراردادِ نمونه | شاهدِ اجرا |
|---|---|---|
| اندازهٔ کل | riffSize+۸ | برابرِ طولِ buffer |
| دادهٔ PCM | dataSize=۱۶ | ۱۶بایتِ واقعاً موجود |
| فریم | ۱۶÷۲ | ۸،برابرِ sampleCount |
| JUNKِ فرد | ۳بایت+۱پد | مرزِ chunk بعدی درست |
خواندنِ محدود، بدون اعتماد به طولِ نامطمئن
کد ابتدا سقفِ کوچکِ bufferِ تمرین را کنترل می‌کند؛ از اندازهٔ اعلامی حافظهٔ چندگیگابایتی تخصیص نمی‌دهد. هر سرآیند، انتهای payload و بایتِ پد باید داخلِ همان بایت‌های موجود باشد. فقط یک fmtِ ساده، یک data و JUNKِ اختیاری را می‌پذیرد؛ خوانندهٔ جامعِ RF64،BW64،قالبِ فشرده یا جدولِ اندازهٔ اضافی نیست.
پنج ورودیِ منفی واقعاً اجرا شده‌اند: ds64ِ مفقود، sentinelِ اشتباهِ RIFF،sentinelِ اشتباهِ data، طولِ کلِ ناسازگار و payloadِ کوتاه‌شده. هرکدام رد می‌شود. ردِ یک ویژگیِ خارج از زیرمجموعهٔ reader به معنیِ نامعتبر بودنِ تمامِ فایل‌های استانداردِ دارای آن ویژگی نیست.
مثالِ بزرگ فقط سرآیند است
نمونهٔ دوم فقط header می‌سازد که dataSize آن۲به‌توان۳۲به‌اضافهٔ۱۶بایت اعلام شده است. هیچ payloadِ بزرگی ساخته یا خوانده نمی‌شود. تابعِ خواندنِ سرآیند، عددِ۶۴بیتی را گزارش می‌کند؛ بازرسیِ فایلِ کامل همان نمونه را به‌دلیلِ نابرابریِ طول رد می‌کند و complete_audio_file نادرست باقی می‌ماند.
این تمایز مهم است: تواناییِ نگه‌داشتنِ عددِ بزرگ در Python، آزمایشِ پردازشِ ضبطِ چندساعته یا پذیرشِ فایلِ چندگیگابایتی در یک سرویس نیست. برای فایلِ واقعی، ابزارِ مناسبِ نسخهٔ قالب، محدودیتِ ورودی و سیاستِ تحویل لازم است. اصلِ ضبط را تغییر ندهید و headerِ ناقص را فایلِ صوتیِ معتبر معرفی نکنید.
این بررسی چه کمکی به آماده‌سازی می‌کند؟
بازرسِ معمولیِ WAV روی PCMِ قابل‌خواندن با wave کار می‌کند؛ اینجا ds64 و sentinelِ RF64 را مستقیم می‌خوانیم. بازرسیِ LIST/INFO هم برچسب‌های توصیفی را می‌بیند و جایِ کنترلِ اندازه را نمی‌گیرد.
برای درخواستِ اپرانگار، مدتِ مورد انتظار و قالبِ واقعیِ ضبط را با تیم مطرح کنید و ورودیِ قابل‌پذیرش را بپرسید. این مثال پشتیبانیِ RF64 یا فایلِ بزرگ را برای اپرا ثابت نمی‌کند. اگر قالب نیاز به تبدیل دارد، روشِ مجاز و حفظِ اصل و تطبیقِ مدت و محتوا را جدا بررسی کنید.
فایل تمرین و منبع
کد کامل تمرین محلی و کنترل‌های ورودی · دادهٔ ساختگی و خروجیِ اجرای واقعیِ تمرین
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.