اندازهٔ فایل صوتی با اندازهٔ نمونه‌های صوت بعد از بازشدن در مرورگر یکسان نیست. برای دیدنِ تفاوت، یک صدای کاملاً ساختگیِ دوثانیه‌ای را واقعاً با decodeAudioData باز کردیم و بایتِ کانال‌های خروجی را شمردیم. این اندازه‌گیری مربوط به محتوای Float32 بافر است؛ مصرفِ کلِ حافظهٔ مرورگر را اندازه نگرفته‌ایم.
فایلِ کوچک‌تر الزاماً بافرِ کوچک‌تر نیست
فایل، سرآیند و دادهٔ ذخیره‌شده با قالبِ مشخص دارد. بافرِ بازشده، نمونه‌های آمادهٔ پردازش را نگه می‌دارد. تعدادِ کانال، تعدادِ فریم و نوعِ نمونه در اندازهٔ این بخش اثر دارند. در Web Audio، دادهٔ هر کانال را می‌توان به شکلِ Float32Array خواند؛ هر عنصرِ این آرایه چهار بایت دارد.
decodeAudioData دادهٔ کاملِ فایل را می‌گیرد و خروجی را با نرخِ زمینهٔ صوتی آماده می‌کند. بنابراین نرخِ ورودی و نرخِ بافر را جدا بخوانید. درخواستِ یک نرخ نیز باید در مرورگر پشتیبانی شود؛ اگر ساختنِ زمینه شکست خورد، آن را نتیجهٔ موفقِ آزمایش حساب نکنید.
آزمایشی که واقعاً اجرا شد
فایلِ همراه با پایتون یک موجِ ۴۴۰ هرتز می‌سازد: دو ثانیه، یک کانال، PCM صحیحِ ۱۶بیتی و نرخِ ۱۶۰۰۰. اندازهٔ کاملِ WAV در همین تمرین ۶۴۰۴۴ بایت است. هیچ صدای انسان، میکروفن یا فایلِ مشتری استفاده نشده و هیچ صدا پخش نشده است. مرورگرِ آزمون Edge نسخهٔ 154.0.4258.37 در محیطِ موقت و جدا بود.
| زمینهٔ واقعاً ساخته‌شده | فریمِ هر کانالِ خروجی | بایتِ نمونه‌های خروجی |
|---|---|---|
| ۲۴۰۰۰ نمونه در ثانیه | ۴۸۰۰۰ | ۱۹۲۰۰۰ |
| ۴۸۰۰۰ نمونه در ثانیه | ۹۶۰۰۰ | ۳۸۴۰۰۰ |
مدتِ خروجی در هر دو اجرا دو ثانیه و کانال یکی بود. فرمولِ کنترل، تعدادِ فریم ضرب‌در تعدادِ کانال ضرب‌در چهار بایت است. مجموعِ byteLength کانال‌ها با همین فرمول برابر شد؛ عددهای جدول از خروجیِ واقعی آمده‌اند، نه فرضِ ثابت دربارهٔ همهٔ فایل‌ها.
چه چیزی را دربارهٔ حافظه نمی‌دانیم؟
این جدول کلِ RAM یا heap نیست. ورودیِ فشرده یا PCM، کپیِ ورودی، اشیای جاوااسکریپت، حافظهٔ رمزگشا و بخش‌های دیگر می‌توانند هم‌زمان جا بگیرند. تابع برای حفظِ ورودی، یک کپی به رمزگشا می‌دهد؛ آن کپی را با محتوای کانال‌های بازشده یکی نگیرید. دو برابرشدنِ بافر در جدول هم اثباتِ دو برابرشدنِ کلِ مصرفِ پردازش نیست.
سقفِ آموزشیِ یک میلیون بایت فقط پیش از بازکردنِ فایل بررسی می‌شود. این سقف، محدودیتِ سختِ حافظهٔ رمزگشا یا پذیرشِ امنِ فایلِ ناشناس نیست. برای فایلِ طولانی، چندکاناله یا ورودیِ نامطمئن، سیاستِ منابع و روشِ پردازش باید جدا طراحی شود؛ این نمونه سیستمِ پردازشِ عملیاتی نیست.
تمرین را چگونه تکرار کنیم؟
- فایلِ پایتون را محلی اجرا کنید؛ دو نشانیِ loopback چاپ می‌کند و فایلِ کاربر نمی‌گیرد.
- نشانیِ اول را در مرورگر باز کنید و تابعِ متنیِ همراه را در ابزارِ توسعهٔ همان صفحه قرار دهید.
- دادهٔ tone.wav را از همان نشانی با fetch بگیرید و برای هر نرخ، inspectTeachingDecodedBuffer را روی ArrayBuffer اجرا کنید.
- نرخِ واقعی، تعدادِ فریم، کانال و payloadBytes را ثبت کنید؛ خطا را با خروجیِ صفر جایگزین نکنید.
در آزمونِ ثبت‌شده، ورودیِ خالی، بیش از سقف، نرخِ خارج از دو گزینهٔ تمرین و بایتِ غیرصوتی رد شدند. این چهار مورد، پوششِ تمامِ خطاهایِ رمزگشا نیستند. زمینه پس از هر اجرا بسته می‌شود؛ نمونه هم‌زمان چند فایل را باز نمی‌کند.
از مشخصاتِ فایل تا نیازِ خروجی
خواندنِ سرآیندِ WAV مشخصاتِ ذخیره‌شده را کنترل می‌کند؛ اینجا خودِ رمزگشا و اندازهٔ کانال‌هایِ خروجی اجرا شده است. پردازشِ فایلِ نامطمئن هم موضوعِ محدودیتِ محیط و اختیار است و با همین محاسبه جایگزین نمی‌شود.
برای درخواست از اپرانگار، نوعِ فایل و مدتِ تقریبی را همراهِ شکلِ متنِ موردنیاز مطرح کنید. این آزمایش روشِ داخلیِ سرویس، سقفِ پذیرش یا کیفیتِ تشخیصِ گفتارِ آن را اعلام نمی‌کند.
فایل تمرین و منبع
سازندهٔ صدای آزمایشی روی localhost، بدون دریافت فایل کاربر · تابع اندازه‌گیری بافرِ بازشده در مرورگر
- MDN؛ ورودیِ کامل و نرخِ بافر پس از decode
- MDN؛ دادهٔ کانال به شکلِ Float32Array
- MDN؛ درخواست و پشتیبانیِ نرخِ زمینه
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.