فایلِ صدا علاوه بر موجِ صوت میتواند برچسبهایی مثلِ عنوان، نامِ سازنده و توضیح داشته باشد. پیش از اشتراک، هم محتوایِ شنیداری و هم اطلاعاتِ توصیفی را بررسی کنید. ابزارِ این صفحه فقط بخشِ مشخصی از RIFF/WAVE را رویِ دستگاهِ خودتان میخواند؛ نه فایل را میفرستد، نه آن را پاکسازی یا بازنویسی میکند.
نامِ فایل، مشخصاتِ فنی و برچسبِ توصیفی یکی نیستند
نرخِ نمونه و تعدادِ کانال مشخصاتِ فنیاند؛ عنوانِ قطعه یا نامِ سازنده میتواند در فیلدِ جدا نوشته شود. عوضکردنِ نامِ فایل، لزوماً این فیلدها را تغییر نمیدهد. از سویِ دیگر، نبودِ عنوان و نام به معنیِ ناشناسبودنِ صدا نیست؛ خودِ گفتار ممکن است نام، شماره یا اطلاعاتِ حساس داشته باشد.
برایِ نرخ، کانال و تطبیقِ طولِ داده از بازرسِ مشخصاتِ فنیِ WAV استفاده کنید. کارِ این ابزار خواندنِ LIST/INFO و نمایشِ محدودِ سه فیلدِ توصیفی است. این دو بررسی مکملاند و هیچکدام مجوزِ انتشارِ فایلِ خصوصی ایجاد نمیکند.
بازرس را بدونِ بارگذاری اجرا کنیم
کد با کتابخانهٔ استانداردِ پایتون اجرا میشود؛ نصبِ بسته، کلیدِ API و ارسالِ اینترنتی لازم ندارد. ابتدا بدونِ آرگومان اجرا کنید تا نمونهٔ ساختگیِ داخلِ حافظه تولید و بررسی شود. برایِ خواندنِ یک فایلِ مجازِ محلی، مسیرش را در گیومه بدهید:
python riff-info-authored-local-inspector.py
python riff-info-authored-local-inspector.py "sample.wav"حالتِ دوم فایل را فقط با rb میخواند. خروجی ممکن است خودِ برچسبِ حساس را نشان دهد؛ گزارش را هم بیبررسی در چت یا فضایِ عمومی نگذارید. این نسخه اندازهٔ کلِ فایل را در حافظه میخواند و برایِ فایلِ بزرگ یا نامطمئن، ابزارِ جامعِ تحلیلِ رسانه نیست.
در نمونهٔ واقعیِ این تمرین چه برچسبی بود؟
برنامه یک سیگنالِ ۴۴۰هرتز، یکدهمِ ثانیه، تککانالهٔ PCM شانزدهبیتی با نرخِ ۸۰۰۰ میسازد. این صدا گفتارِ انسان یا دادهٔ مشتری نیست. سپس یک LIST با نوعِ INFO و سه برچسبِ ASCIIِ ساختگی و یک فیلدِ ناشناخته به نسخهٔ جدا اضافه میکند:
| شناسه | مقدارِ نمونه | بایتِ مقدار |
|---|---|---|
| INAM | Demo | 5 |
| IART | Fictional author | 17 |
| ICMT | Authored local fixture | 23 |
| XTRA | بایتِ ناشناخته؛ تفسیر نشده | 3 |
INAM عنوان، IART سازنده و ICMT توضیحِ نمونهاند. مقدارها با بایتِ صفر پایان یافتهاند. برایِ XTRA معنیِ اختراعی نمینویسیم؛ طول و بایتِ خام در گزارش میمانند. ASCIIِ این مثال به معنیِ پشتیبانیِ درست از همهٔ متنهایِ فارسی و کدگذاریهایِ فایلهایِ واقعی نیست.
چرا اندازه و پدینگ را کنترل میکنیم؟
در RIFF، هر chunk شناسهٔ چهاربایتی و اندازهٔ little-endian دارد. اندازهٔ chunk خودِ سرآیندِ هشتبایتی و پدینگ را حساب نمیکند؛ مقدارِ فرد برایِ ترازِ دوبایتی یک بایتِ اضافه دارد. کد محدودهٔ هر فرزند را با والد میسنجد و طولِ اعلامیِ RIFF را با طولِ واقعی برابر میخواهد. صرفِ پیداکردنِ واژهٔ IART در بایتها، بازخوانیِ درستِ ساختار نیست.
سه ورودیِ منفی واقعاً آزموده شدند: فایلِ کوتاهشده، اندازهٔ بزرگتر از محدودهٔ اولین chunk و سرآیندِ RIFX که خارج از قراردادِ این نسخه است. ردِ موردِ سوم به معنیِ خرابیِ همهٔ فایلهایِ RIFX نیست؛ بازرسِ ما فقط RIFF little-endian را پیاده کرده است.
هشِ موج ثابت ماند، هشِ کلِ فایل عوض شد
هشِ SHA-256ِ دادهٔ chunkِ data قبل و بعد برابر بود، اما هشِ کلِ فایل تغییر کرد. این کنترل میگوید در همین مثال بایتهایِ PCM عوض نشدهاند؛ کیفیتِ شنیداری، سازگاریِ همهٔ پخشکنندهها یا محرمانگی را تأیید نمیکند. فایلِ بیبرچسبِ نمونه هم هنوز موجِ صوت دارد.
پس از دیدنِ گزارش چه تصمیمی بگیریم؟
عنوان و توضیح را با هدفِ اشتراک مقایسه کنید و اصلِ فایل را محفوظ نگه دارید. برایِ حذفِ داده، مسیرِ مجاز و ابزارِ مناسبِ همان قالب لازم است؛ این کد حذف انجام نمیدهد. محتوایِ bext، iXML و ID3 و قالبهایِ RF64، RIFX و MP3 اینجا تفسیر نشدهاند. خالیبودنِ فهرستِ INFO، گواهِ نبودِ همهٔ متادیتا نیست.
اگر فایل برایِ درخواستِ اپرانگار آماده میشود، قالبِ تحویل و اجازهٔ استفاده را با تیم روشن کنید. برایِ پیگیریِ تغییرها، دفترِ هشِ اصل و نسخهٔ کاری را جدا نگه دارید؛ از این ابزار وعدهٔ ناشناسسازیِ کامل نگیرید.
فایل تمرین و منبع
دریافتِ بازرسِ محلیِ فقطخواندنیِ INFO در RIFF/WAVE · گزارشِ واقعیِ فایلِ بیبرچسب، برچسبدار و سه ورودیِ ردشده
- مستندِ اصلیِ Microsoft؛ RIFF، اندازهٔ chunk و پدینگ؛ تاریخِ بهروزرسانیِ ۷ ژانویهٔ ۲۰۲۱
- مشخصاتِ اصلیِ IBM/Microsoft، اوتِ ۱۹۹۱؛ فقط بخشِ LIST/INFO و INAM/IART/ICMT در صفحاتِ چاپیِ ۲–۱۴ و ۲–۱۵ خوانده شد
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثالها و فایلهای این راهنما آموزشی و ساختهٔ تحریریهاند.