PCM خام معمولاً اطلاعاتِ کافی برایِ تفسیرِ خودش ندارد. پیش از بازکردن، باید نرخِ نمونه، تعدادِ کانال، نوعِ عدد، اندازهٔ نمونه، ترتیبِ بایت و چیدمانِ کانال‌ها را بدانید. انتخابِ شانسیِ تنظیمی که «صدایی» تولید می‌کند، قراردادِ درست را ثابت نمی‌کند. این تمرین دوازده بایتِ ساختگی را با چند قرارداد می‌خواند؛ فایلِ مشتری یا پخش‌کننده اجرا نشده است.
PCM خام با ظرفِ WAV فرق دارد
در فایلِ دارایِ ظرف، بخشی از این مشخصات در سرآیند می‌آیند؛ یک جریانِ خام ممکن است چنین راهنمایی نداشته باشد. تغییرِ پسوند به wav، سرآیند و قرارداد اضافه نمی‌کند. اگر فایلِ واقعی WAV است، اول مشخصاتِ فنیِ ظرف را بخوانید؛ برایِ دادهٔ خام از مستندِ مبدأ یا تنظیمِ معتبرِ ضبط کمک بگیرید.
در این تمرین قرارداد را خودمان تعیین کرده‌ایم: عددِ صحیحِ علامت‌دارِ شانزده‌بیتی، little-endian و دو کانالِ درهم‌تنیده. نرخِ ۸۰۰۰ فقط فرضِ زمانی است و از بایت‌ها کشف نمی‌شود. این تنظیم، پیشنهادِ ورودیِ همهٔ سرویس‌هایِ تشخیصِ گفتار یا مشخصاتِ API اپرا نیست.
سه فریم را قبل از بسته‌بندی ببینیم
زوج‌هایِ چپ و راست عبارت‌اند از [۱،۲۵۶]،[−۲،−۵۱۲] و[۳۰۰،−۳۰۰]. هر فریم دو نمونه و چهار بایت دارد؛ سه فریم دوازده بایت می‌سازند. کد ابتدا همان زوج‌ها را با struct بسته‌بندی می‌کند و بعد مسیرِ خواندنِ درست و غلط را جدا اجرا می‌کند. JSON هم hexِ کامل را نگه می‌دارد تا عددهایِ گزارش به دادهٔ قابل بررسی وصل باشند.
در حالتِ interleaved ترتیبِ منطقی L0,R0,L1,R1,L2,R2 است. اگر همین شش عدد را planar فرض کنیم و نیمهٔ اول را کانالِ چپ بگیریم، زوج‌هایِ دیگری ساخته می‌شوند؛ بایتِ جدیدی وارد نشده، معنیِ چیدمان عوض شده است. این خطا با عوض‌کردنِ نرخِ نمونه حل نمی‌شود.
ترتیبِ بایت چه چیزی را تغییر داد؟
همان دوازده بایت با big-endian هم به شش عدد تبدیل می‌شوند، اما مقدارها با قراردادِ اصلی برابر نیستند. کوچک یا بزرگ‌بودنِ عددِ خروجی، به‌تنهایی شاهدِ انتخابِ درست نیست. نویسنده قرارداد را از مبدأِ ساختِ مثال می‌داند؛ ابزار از رویِ شکلِ بایت‌ها آن را حدس نزده است.
| خواندنِ همان داده | چیزی که عوض می‌شود |
|---|---|
| دوکاناله، little-endian | سه زوجِ اصلی بازیابی می‌شوند |
| دوکاناله، big-endian | سه زوج داریم، اما مقدارهایِ نمونه متفاوت‌اند |
| تک‌کاناله، little-endian | شش فریمِ تک‌کاناله به‌جایِ سه فریمِ استریو |
| چیدمانِ planar | جفت‌شدنِ چپ و راست تغییر می‌کند |
تعدادِ کانال را با تعدادِ گوینده اشتباه نگیریم
در نرخِ فرضیِ یکسان، سه فریمِ استریو مدتِ ۳÷۸۰۰۰ ثانیه دارند؛ خواندنِ اشتباهِ تک‌کاناله شش فریم و مدتِ دوبرابر می‌سازد. این اختلافِ محاسبهٔ زمان در کد کنترل شده است. اما استریو بودن نمی‌گوید دو نفر حرف زده‌اند؛ در اینجا اصلاً گفتاری وجود ندارد و عددها فقط برایِ دیده‌شدنِ خطا انتخاب شده‌اند.
برنامه دادهٔ ناقصِ یازده‌بایتی را رد می‌کند، چون فریمِ چهاربایتی کامل نیست. کانالِ خارج از دامنهٔ تمرین و قراردادِ نامعتبرِ ترتیب هم رد می‌شوند. این سه کنترل تمامِ قالب‌هایِ PCM را پوشش نمی‌دهند؛ PCM شناور، ۲۴بیتی و چیدمان‌هایِ دیگر در این نسخه پیاده نشده‌اند.
پیش از تبدیل، قرارداد را تحویل بگیرید
از مبدأ بپرسید فرمتِ دقیقِ نمونه و چیدمانِ کانال چیست و یک خروجیِ مجازِ کوتاه با مشخصاتِ معتبر بگیرید. اصل را نگه دارید؛ اگر پس از تفسیر هنوز صدایِ نامناسب شنیده می‌شود، علت می‌تواند ضبط، کدکِ دیگری یا دادهٔ ناقص باشد. این مثال تشخیصِ خودکارِ نویز و تعمیرِ صوت انجام نمی‌دهد.
بافردار خواندنِ فریمِ جزئی مسئلهٔ مرزِ دریافت را حل می‌کند؛ اینجا مسئله، معنیِ بایت‌هایِ کامل است. برایِ تحویلِ صوت به اپرانگار، قالبِ قابل‌قبول و مسیرِ ارسال را از تیم بخواهید؛ از این قراردادِ آموزشی، سازگاریِ محصول را نتیجه نگیرید.
فایل تمرین و منبع
سه قراردادِ تفسیرِ همان دوازده بایتِ PCM16 را اجرا کنید · بایت‌هایِ ثابت، سه فریمِ درست و تفسیرهایِ غلطِ واقعاً محاسبه‌شده
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.