بخش 5 از مجموعه مقالاتی که پروتکل MIDI را شرح می دهد.

یکی از سه بخش پروتکل MIDI، مشخصات فرمت ذخیره سازی داده ها است (به یاد داشته باشید، دو قسمت دیگر فرمت پیام و مشخصات رابط سخت افزاری هستند). قالب پیام در سه مقاله اول این مجموعه مورد بحث قرار گرفت، اکنون زمان فرمت ذخیره سازی است. در اواخر سال 1987 توسط سازمان MMA پیشنهاد شد و استاندارد MIDI Files (SMF) نام گرفت.

هدف فایل‌های MIDI این است که رویدادها (یعنی پیام‌های MIDI دارای مهر زمانی) بین دستگاه‌ها و برنامه‌های مختلف رد و بدل شوند. قبل از ظهور فایل‌های MIDI استاندارد، ترتیبی که در یک ترتیب‌دهنده تهیه شده بود، به دلیل ناسازگاری فرمت‌ها در دیگری بارگذاری نمی‌شد. این بدان معنا نیست که با ظهور SMF، همه سازندگان ترتیب سنج به این فرمت تغییر داده اند. دلایل متعددی برای این امر وجود دارد و ما نیز امروز در مورد آنها صحبت خواهیم کرد.

از آنجایی که ذخیره سازی اطلاعات به طور مستقیم با دستگاه ترتیب دهنده ها مرتبط است، ما در این مورد با جزئیات بیشتری صحبت خواهیم کرد، اما فقط تا حدی که برای درک SMF لازم است. و بدون شک یکی از مقالات بعدی این چرخه را به ترتیب‌دهنده‌ها اختصاص خواهیم داد.

مناسبت ها
یک پیام MIDI با مهر زمانی فراخوانی می شود رویداد... واحدهای مختلفی را می توان برای نشان دادن زمان استفاده کرد - تیک ها، پالس های داخلی، زمان در قالب SMPTE و غیره. درک تفاوت اساسی بین یک رویداد و یک پیام مهم است. پیام "زندگی می کند" برای کسری از میلی ثانیه از زمان واقعی - از لحظه ای که توسط منبع تولید می شود تا لحظه ای که برای اجرا به گیرنده ارسال می شود. می توان آن را در فرآیند انتقال از طریق کابل MIDI به شکل مجموعه ای از پالس ها گرفت. یک رویداد چند بایت از اطلاعات ثبت شده در حافظه دستگاه است که بر اساس آن پیامی در آینده و در زمان تعیین شده تولید خواهد شد.

برای مثال، ترتیب‌دهنده می‌تواند یک رویداد "انتخاب یادداشت" را با مهر زمانی 100 میلی‌ثانیه از شروع پخش ذخیره کند. شما می توانید این رویداد را در دو بعد ویرایش کنید: اولاً پارامترهای خود پیام MIDI (در این مورد، گام یا پویایی نت) را تغییر دهید و ثانیاً نت را در طول مسیر حرکت دهید، یعنی زمان اجرا را تغییر دهید. از پیام

هنگام ضبط پیام‌های MIDI، رویدادها در حافظه ترتیب‌دهنده ظاهر می‌شوند. هنگامی که دکمه ضبط را فشار می دهید، ترتیب سنج مولد پالس سخت افزاری را روشن می کند (تیک) و شروع به "گوش دادن" به ورودی MIDI مشخص شده می کند. به عنوان مثال، هنگامی که یک کلید را فشار می دهید، ورودی پیام "انتخاب یک یادداشت" را دریافت می کند. ترتیب دهنده نگاه می کند - آها، پیام به تیک 20 رسید و آن را با برچسب 20 در حافظه می نویسد. بعد از چند ثانیه کلید را آزاد کردند - پیام "حذف یادداشت" آمد، ژنراتور داخلی با خوشحالی 64 را تکان داد. در آن لحظه به ترتیب دهنده تیک می زند. ترتیب‌دهنده پیامی را با برچسب 64 ذخیره می‌کند. اکنون با دو رویداد روبرو هستیم - Note On و Note Off. در حین پخش، مولد پالس دوباره روشن می شود. هنگامی که تیک بیستم بالا می آید، یک پیام Note On به خروجی MIDI ترتیب دهنده ارسال می شود، تیک 64 یک Note Off است. کارهای مجری را ضبط و سپس پخش کردیم!

بدیهی است که همین کار را می توان به صورت آفلاین یعنی بدون نیاز به اجرای زنده انجام داد. با کلیک کردن روی ماوس در مکان مناسب در مسیر (و با انتخاب مدت زمان یادداشت از قبل)، دقیقاً تصویر قبلی را در حافظه ترتیب‌دهنده می‌سازیم.

انواع حافظه
اکنون زمان استفاده از دو عبارت سخت کامپیوتری است: حافظه اولیه و ثانویه. حافظه اولیه (یا داخلی) حافظه ترتیب‌دهنده است که در آن پیام‌ها ضبط می‌شوند و رویدادها در کل جلسه ذخیره می‌شوند. محتویات این حافظه با قطع برق پاک می شود. این تعبیر بیشتر برای ترتیب دهنده های سخت افزاری مناسب است. در ترتیب‌دهنده‌های نرم‌افزار، حافظه اصلی صرفاً RAM رایانه است. برای ذخیره محتویات حافظه اولیه برای مدت طولانی از حافظه ثانویه یا به عبارتی حامل های داده استفاده می شود. این می تواند فلاپی دیسک، هارد دیسک، کارت هوشمند و موارد مشابه باشد.

مقدار حافظه اولیه در ترتیب‌دهنده‌ها و ایستگاه‌های کاری سخت‌افزاری (به یاد داشته باشید، یک ایستگاه کاری یک مولد آهنگ و ترتیب‌دهنده در یک جعبه است) معمولاً با تعداد یادداشت‌های ذخیره شده (مثلاً 200 هزار) بیان می‌شود. گاهی اوقات صدا به صورت رویدادها بیان می شود، در این مورد باید مراقب خود باشید - یک نت به دو رویداد برای ذخیره نیاز دارد (فشردن و رها کردن یک کلید)، و چرخاندن چرخ یا پس از لمس می تواند تا 100 یا بیشتر رویداد ایجاد کند. این اتفاق می افتد که اندازه حافظه یک ترتیب دهنده در واحدهای کامپیوتری بومی - کیلوبایت بیان می شود. اما این نیز خیلی راحت نیست - یک رویداد می تواند تعداد متفاوتی از بایت ها (از پنج تا چند ده) را اشغال کند.

در ترتیب‌دهنده‌های نرم‌افزاری مدرن، افراد کمی به میزان حافظه اولیه اهمیت می‌دهند - حتی در دستگاهی با 128 مگابایت رم، می‌توانید هنگام کار با داده‌های MIDI، محدودیت‌ها را فراموش کنید. علاوه بر این، ترتیب‌دهنده‌هایی وجود دارند که می‌توانند ترتیبی را مستقیماً از دیسک پخش کنند، بدون اینکه آن را در حافظه اصلی بارگذاری کنند (و اتفاقاً آن را نیز ضبط کنند)، که به طور کلی تمایز بین این دو نوع حافظه را پاک می‌کند.

در حافظه ثانویه، داده ها معمولاً در یک فایل نوشته می شوند. اکثر ترتیب‌دهنده‌ها فرمت اختصاصی خود را از این فایل دارند، که تبادل ترتیبات ایجاد شده در دستگاه‌ها یا برنامه‌های مختلف را دشوار می‌کند. قبلاً گفته شد که این دلیل اصلی ایجاد SMF بود.

اندازه گیری زمان
در واقع، هیچ "تیک" در داخل ترتیب دهنده وجود ندارد. یک تایمر سخت افزاری وجود دارد که پالس هایی با فرکانس کاملاً ثابت (مثلاً هر میکروثانیه) تولید می کند. مجبور کردن نوازندگان برای اندازه‌گیری زمان در میکروثانیه، مانند سایر واحدهای زمان واقعی (ثانیه، دقیقه) یک تمسخر وحشتناک خواهد بود. نوازندگان عادت دارند که در میله‌ها و بیت‌ها فکر کنند و زمان را به واحدهای نسبی (مدت زمان نت) بیان کنند، بسته به سرعت فعلی.

تولیدکنندگان پاسخ دادند: "مشکلی نیست، بگذارید اندازه گیری کنند زیرا برای آنها راحت تر است." فقط حداقل واحد اندازه گیری مدت زمان سی و دوم نیست، بلکه یک تیک معمولی است (واحد حتی کوچکتر است، به طوری که برای مثال، یک سی و ثانیه می تواند حاوی 48 تیک باشد). از آنجایی که از دوران کلاسیک، سرعت با تعداد ربع در دقیقه (BPM، ضربان در دقیقه) اندازه‌گیری می‌شد، سپس تصمیم گرفتند یک چهارم را به عنوان مدت زمان اصلی در نظر بگیرند و تعداد تیک‌ها را در یک چهارم نشان دهند - PPQN (Pulse Per یادداشت چهارم). هر چه PPQN بزرگتر باشد، وضوح ترتیب دهنده بهتر است و از نظر زمانی دقیق تر می تواند پیام ها را در حین ضبط ضبط کند و در حین پخش آنها را به خروجی MIDI ارسال کند. اکثر ترتیب‌دهنده‌ها به شما اجازه می‌دهند تا PPQN را خودسرانه تنظیم کنید - برای مثال، از 32 تا 1536 تیک در هر سه ماه (توالی‌سنجی‌های مدرن - تا 15360 PPQN).

تیک یک واحد وابسته به نرخ است: هر چه نرخ سریعتر باشد، فاصله بین تیک ها در واحدهای زمان واقعی کوتاهتر است. این فاصله را می توان با فرمول در شکل 1 یافت. یکی

به عنوان مثال، در 120 BPM و 96 PPQN، تیک ها هر 5.208 میلی ثانیه دنبال می شوند. در همان وضوح و 180 BPM، فاصله بین تیک ها به 3.472 میلی ثانیه کاهش می یابد. اگر تایمر داخلی آن در هر میکروثانیه پالس کند، ترتیب‌دهنده چگونه تیک‌ها را می‌شمرد؟ این بسیار ساده است: بر اساس سرعت فعلی و وضوح در یک چهارم، دقیقا مطابق با فرمول مشخص شده. از آنجایی که یک میلی ثانیه حاوی 1000 میکروثانیه است، در آخرین مثال، ترتیب سنج با دریافت 3472 پالس از تایمر، تیک دیگری ایجاد می کند.

موقعیت یک رویداد در خط زمانی در ترتیب‌دهنده تنظیم می‌شود، معمولاً در قالب "bars: beats: ticks"، به عنوان مثال، 22: 3: 152. یعنی: پیمانه بیست و دوم، ضرب سوم، تیک 152 از ابتدای ضرب سوم. این اصل زمان بندی (اصطلاح انگلیسی - Timebase) موزیکال نامیده می شود، زیرا برای نوازندگان آشنا و راحت است. لطفاً توجه داشته باشید که برای کار در این قالب باید امضای زمان فعلی را بدانید. یعنی پیمانه شامل چند ضربه است و هر ضربه برابر است.

بنابراین، با امضای زمان 4/4، یک ضرب برابر با یک چهارم است و یک پیمانه شامل چهار ضربه است. در رزولوشن 384 PPQN، 384 تیک در یک ضرب و 1536 تیک در هر تیک (384 x 4) وجود خواهد داشت. در 6/8 و وضوح یکسان، یک ضرب 192 تیک خواهد بود (یک هشتم به اندازه نصف یک چهارم است)، و یک اندازه دارای شش ضربه یا 1152 تیک (192 x 6) خواهد بود. بنابراین، 22: 3: 152 در حالت اول به معنای 35096 تیک از ابتدای آهنگ (22 x 1536 + 3 x 384 + 152)، و در مورد دوم - 26072 تیک (22 x 1152 + 3 x 192 + 152) است. .

بنابراین، برای تعیین موقعیت یک رویداد در واحدهای زمان واقعی بر اساس قالب "bars: beats: ticks"، باید سه پارامتر را بدانید: سرعت فعلی، امضای زمان و وضوح بر حسب تیک در هر سه ماه (PPQN).

امکان دیگری برای زمان بندی وجود دارد، زمانی که موقعیت یک رویداد در یک مسیر در واحدهای مطلقی که به سرعت بستگی ندارد بیان می شود، اغلب در قالب زمان SMPTE - "ساعت: دقیقه: ثانیه: فریم". این اصل زمان‌بندی، «مبتنی بر کد زمان» (مبتنی بر کد زمانی، مطلق) نامیده می‌شود. نیاز به آن زمانی ایجاد می شود که ترتیب دهنده با یک ضبط صوت یا تجهیزات فیلم / فیلم با هم کار می کند. عملیات ویرایش با فیلم، ویدئو و مواد صوتی، مشخص کردن موقعیت های شروع و پایان ضبط برای انجام راحت تر است، به مقیاس مطلق گره خورده است، و نه به اندازه گیری ها و ضربات.

در این حالت، مختصات رویداد روی خط کش زمان به سرعت فعلی بستگی دارد. بنابراین با سرعت 120 BPM، ضربان اول اندازه گیری دوم می تواند زمان SMPTE 00: 00: 02: 00 و با سرعت 60 BPM - 00: 00: 04: 00 داشته باشد. هنگامی که یک رویداد در یک فریم (بین ثانیه) قرار می گیرد، مختصات آن نیز با فرمت فریم متفاوت (تعداد فریم در ثانیه) متفاوت خواهد بود. در مقاله قبلی این مجموعه می توانید اطلاعات بیشتری در مورد SMPTE و MIDI Time Code بخوانید.

مقادیر طول متغیر
انحرافات غنایی کافی است، اکنون وظیفه ما درک قالب ذخیره سازی داده ها است. و اولین چالشی که توسعه دهندگان SMF با آن مواجه شدند این بود که چگونه زمان برگزاری رویداد را حفظ کنند.

در اینجا دو گزینه وجود دارد: ذخیره برای هر رویداد زمان از ابتدای آهنگ، یا از آخرین رویداد قبل از آن (در همان کانال). با این حال، گزینه اول منطقی نیست، زیرا اغلب فاصله بین رویدادها کوچک است، رویدادهای مجاور زمان اجرا نزدیک به یکدیگر دارند. بنابراین، در یک قطعه سه نت، اولی می تواند زمان داشته باشد، مثلاً 22: 3: 152، دومی - 22: 3: 244، سومی - 22: 3: 288. برای ذخیره این اعداد (که از ابتدای آهنگ به تیک ترجمه شده اند)، باید حداقل چهار بایت برای هر کدام رزرو کنید. اگر در امتداد مسیر دوم بروید، به جای سه عدد بزرگ، می توانید یک شروع بزرگ را ذخیره کنید (22: 3: 152)، و پس از آن - دو عدد کوچک، تفاوت تیک بین اول و دوم و دوم و نت های سوم (در این مورد 92 و 44) یک بایت برای آنها کافی است. اما همچنان، مشکل همچنان پابرجاست: بسته به رویداد، باید تعداد متفاوتی از بایت ها را برای صرفه جویی در زمان اختصاص دهید.

اگر SMF در حال حاضر توسعه می یافت (و حتی توسط مایکروسافت، که عموماً به اندازه فایل ها و حافظه مورد نیاز خود اهمیت چندانی نمی دهد)، این مشکل چشم پوشی می کرد. ما یک فیلد ثابت را برای صرفه جویی در زمان اختصاص دادیم، مثلاً 8 بایت در هر رویداد، و متضرر نشدیم. با این حال، در سال 1988، حافظه اولیه (RAM) بسیار گران بود، هر بایت شمارش می‌شد و ثانویه (رسانه دیسک) اندازه بسیار کمی داشت. بنابراین، توسعه دهندگان SMF می خواستند فشرده ترین قالب ممکن را دریافت کنند.

تصمیم گرفته شد حفظ شود زمان دلتا، یعنی تفاوت تیک بین این رویداد با رویداد قبلی (یا ابتدای آهنگ). به عنوان مثال، اگر اولین رویداد - زدن نت به اکتاو اول - در زمان 40 تیک از ابتدای آهنگ رخ دهد، آنگاه زمان دلتای آن 40 خواهد بود. اگر پس از چهار تیک نت F پخش شود. آنگاه زمان دلتای آن 4 خواهد بود. اگر دو رویداد به طور همزمان رخ دهند، به یکی از آنها زمان دلتای برابر با صفر اختصاص داده می شود. اگر رویداد دقیقاً در ابتدای آهنگ رخ دهد، زمان دلتای آن نیز صفر است. با این حال، رویداد بعدی می تواند در یک ساعت و نیم (یعنی در چند میلیون تیک) رخ دهد. چگونه در این مورد باشیم؟ از این گذشته ، حافظه باید ذخیره شود و تخصیص یک میدان ثابت چند بایت برای زمان دلتا نامطلوب است.

به اصطلاح طول های متغیر... آنها روشی مناسب برای نوشتن اعداد صحیح، از کوچکترین به بزرگ ترین، بدون نیاز به تخصیص تعداد ثابتی از بایت ها برای عدد ارائه می کنند. بیت های شماره اصلی در یک یا چند بایت بسته بندی می شوند: هر بایت دارای هفت بیت است (در سمت راست، بیت های 0 تا 6). مهم ترین بیت در یک بایت سرویس است. تمام بایت های سری، به جز بایت آخر، باید دارای یک باشند، آخرین بایت - صفر. چندین نمونه بسته بندی در شکل نشان داده شده است. 4.

به عنوان مثال، شما باید عدد 64 (هگز 0x40) را در قالب طول متغیر بسته بندی کنید. به صورت دودویی، این عدد به صورت 0100 0000 نوشته می شود. فقط هفت بیت مهم وجود دارد، بنابراین این عدد بدون تغییر در یک بایت بسته بندی می شود - 0100 0000 (این همچنین آخرین بایت سری است)، مهم ترین بیت 0 است.

اکنون عدد 128 (0x80) است. به صورت دودویی، به صورت 1000 0000 نوشته می شود. هشت بیت مهم وجود دارد، بنابراین همه چیز در یک بایت قرار نمی گیرد، باید آن را به دو قسمت تقسیم کنید. بایت اول باید دارای یکی در مهم ترین بیت باشد، بایت دوم (به عنوان بایت پایانی سری) - صفر باشد. ما هفت بیت کم اهمیت از عدد اصلی را در بایت دوم قرار می دهیم، 0 000 0000 به دست می آید. عدد 0x80 به صورت دو بایت نوشته می شود: 0x81 0x00. باز کردن بسته بندی بسیار ساده است. ما از قبل نمی دانیم که چند بایت در این سری وجود دارد. ما اولین بایت را خواندیم - 1000 0001. مهم ترین بیت سرویس (1) نشان می دهد که این آخرین بایت سری نیست، بایت های بیشتری وجود دارد. واحد سرویس را دور می اندازیم و هفت بیت باقی می گذاریم - 000 0001. بایت دوم را بخوانید - 0000 0000. مهم ترین بیت سرویس (0) نشان می دهد که این آخرین بایت سری است (یعنی فقط دو بایت در بایت وجود دارد. سلسله). بیت سرویس را کنار می گذاریم. همچنین هفت بیت باقی مانده است - 000 0000. ما به آنها در سمت چپ هفت بیت اختصاص داده شده از بایت اول را اضافه می کنیم، 000 0001 000 0000 بدست می آوریم. با دور انداختن شش صفر اول، عدد مورد نیاز 1000 0000 (0x80) را بدست می آوریم.

بنابراین، روش طول های متغیر اجازه می دهد تا تعداد بایت های مختلف برای اعداد مختلف تخصیص داده شود: برای اعداد در محدوده 0 تا 127 - یک بایت، از 128 تا 16383 - دو بایت و غیره. حداکثر تعداد ارائه شده در این روش، در اصل، محدود نیست. با این حال، در SMF، طول انفجار به چهار بایت محدود می شود (سه بایت با مهم ترین مجموعه بیت و یک بایت با صفر خاتمه می یابد). در نتیجه، حداکثر زمان دلتا می تواند 0x0FFFFFFFF (یا 268 435 455 تیک) باشد که با نرخ 500 BPM و وضوح 96 PPQN حدود چهار روز است. بیش از اندازه کافی!

در قالب مقادیر طول متغیر، SMF نه تنها زمان دلتا، بلکه طول برخی رویدادها را نیز نشان می دهد.

تبادل فرمت فایل (IFF)
ساختار فایل استاندارد MIDI تقریباً به طور کامل از IFF (فرمت فایل تبادلی) گرفته شده است که در سال 1985 توسط Electronic Arts توسعه یافت. این یک فرمت ذخیره سازی و تبادل داده است که زندگی را برای کاربران و توسعه دهندگان نرم افزار برای نزدیک به بیست سال آسان تر کرده است. الکترونیک آرتز نه تنها اسناد منبع باز، بلکه کد منبع C را برای خواندن و نوشتن فایل‌های IFF ارائه می‌کند.

فرمت IFF سازگار و قابل توسعه است. اولی به این معنی است که نسخه جدید برنامه می تواند فایل های ایجاد شده توسط نسخه قبلی را بدون هیچ مشکلی بخواند. دوم، برای ذخیره اطلاعات اضافی نیازی به اختراع قالب جدیدی ندارید، کافی است پسوند خود را در IFF وارد کنید. ساختار قالب به برنامه‌های تولیدکنندگان مختلف اجازه می‌دهد تا داده‌هایی را که توافقات تجاری مناسبی بین خود ندارند، مبادله کنند. همه اینها کاربران را خوشحال می کند - با ذخیره داده ها در قالب IFF، آنها دیگر به قالب بسته سیستم خود متصل نیستند و می توانند از داده ها در هر نرم افزار و محیط سخت افزاری سازگار با IFF استفاده کنند.

فایل IFF مجموعه ای از داده ها است که به گونه ای سازماندهی شده اند که برنامه های مختلف و نامرتبط بتوانند آن را بخوانند. از سوی دیگر، برنامه می تواند اطلاعات خاصی را در IFF ذخیره کند که فقط برای خودش معنادار است. ساختار IFF این کار را آسان می کند. سایر برنامه هایی که نمی دانند چگونه با چنین اطلاعاتی کار کنند، می توانند بدون به خطر انداختن خواندن محتوای اصلی، آن را نادیده بگیرند.

انواع مختلفی از فایل های IFF وجود دارد. برای مثال، فایل‌های ILBM و GIFF حاوی اطلاعات گرافیکی، فایل‌های SMUS حاوی نت موسیقی و فایل‌های AIFF و WAVE حاوی صدای دیجیتال هستند.

یک فایل IFF از عناصر مشابهی به نام chunk تشکیل شده است. بلوک یک ساختار داده ای است که از یک شناسه الفبایی (چهار کاراکتر ASCII)، اندازه بلوک (چهار بایت) و خود داده تشکیل شده است (شکل 5). راحت است که یک بلوک را به عنوان پوسته ای در نظر بگیریم که داده ها در آن "پیچیده شده اند". خود داده ها می توانند شامل هر چیزی باشند: گرافیک، متن، انیمیشن، صدا، مجموعه ای از اشیاء سه بعدی و غیره.

بلوک ها در فایل IFF می توانند تو در تو باشند، شکل. 6. در واقع، یک فایل IFF چیزی نیست جز یک بلوک سطح بالا که حاوی یک یا چند بلوک دیگر در داخل آن است. این اصل ذخیره سازی داده به شما امکان می دهد چندین داده ناهمگن را در یک فایل، از جمله چندین فایل IFF، که قبلاً شبیه یک سیستم فایل داخل یک فایل است، "پیچ" کنید. درست است، با سازماندهی داده های تودرتو، یک اشکال وجود دارد - تفسیر فایل، جداسازی بلوک ها از آن دشوار می شود.

اکثر فایل های IFF حاوی یک بلوک سطح بالا با شناسه "FORM" هستند. این شامل بلوک های دیگر است (شکل 7). تنها داده در بلوک FORM چهار بایت است که نوع فایل را توصیف می کند (به عنوان مثال "ILBM"، InterLeaved Bit Map). بلافاصله پشت این بلوک‌های تودرتو مانند «BMHD» (سرصفحه تصویر)، «CMAP» (پالت)، و «BODY» (خود پیکسل‌ها) قرار دارند. نام بلوک ها و قالب داده ها توسط توسعه دهنده نوع فایل خاص اختراع می شود. سایر برنامه‌ها، اگر به بلوکی با نام ناآشنا برخورد کنند، می‌توانند با خیال راحت از آن بگذرند و با فیلد حاوی طول بلوک هدایت شوند.

تمام داده‌های عددی در فایل‌های IFF به ترتیب بزرگ ذخیره می‌شوند، یعنی ابتدا مهم‌ترین بایت عدد (MSB) و سپس کم‌اهمیت‌ترین بایت ذخیره می‌شود. برای اطلاعات بیشتر در این مورد به نوار کناری مراجعه کنید. بلوک های درون یک فایل همیشه باید با یک بایت زوج شروع شوند. اگر بلوک قبلی دارای تعداد فرد بایت باشد، با یک بایت تهی به زوج اضافه می شود.

ساختار SMF
فایل های استاندارد MIDI، مانند فایل های IFF، از Chunks تشکیل شده اند. در مجموع دو نوع تکه وجود دارد: Header Chunk و Track Chunk. در یک فایل SMF فقط یک بلوک هدر و یک یا چند بلوک آهنگ وجود دارد. بلوک دارای یک ساختار معمولی IFF است: چهار بایت اول شناسه هستند، چهار بایت بعدی طول بلوک بر حسب بایت است، بدون در نظر گرفتن نوع / طول هشت بایت. شناسه بلوک هدر چهار کاراکتر "MThd" و شناسه بلوک آهنگ چهار کاراکتر "MTrk" است. این ساختار امکان تعریف انواع بلوک های جدید را در آینده فراهم می کند و یک بلوک ناآشنا را می توان به راحتی بر اساس طول آن نادیده گرفت. مشخصات SMF هشدار می دهد: "برنامه ها باید طوری آماده شوند که وقتی با بلوک هایی از انواع ناشناخته روبرو می شوند، آنها را نادیده بگیرند."

بلوک هدر حاوی اطلاعات کلی در مورد فایل است، بلوک آهنگ حاوی جریانی از پیام های MIDI با مهر زمانی است. علاوه بر این، فایل MIDI اطلاعات اضافی لازم برای ترتیب دهنده ها را ذخیره می کند: تمپو، امضای زمان، کلید، تنظیمات مترونوم و موارد مشابه. این اطلاعات از طریق رابط MIDI منتقل نمی شود و رویدادهایی که آن را تشکیل می دهند، متا رویداد نامیده می شوند.

یک فایل MIDI همیشه با یک بلوک هدر و سپس یک یا چند بلوک آهنگ شروع می شود (شکل 9). یعنی هر فایل MIDI استاندارد با چهار حرف "M"، "T"، "h"، "d" شروع می شود. این بدان معناست که فایل MIDI با مشخصات IFF مطابقت ندارد (که مستلزم آن است که هر فایل منطبق با IFF با یک بلوک سطح بالای یکی از سه نوع - "FORM"، "CAT" یا "LIST" شروع شود). تفاوت های دیگری نیز وجود دارد: SMF ها نمی توانند بلوک های تودرتو داشته باشند و طول بلوک نباید یکسان باشد. با این حال، تبدیل یک SMF به یک فایل سازگار با IFF ساده است. کافی است بلوک های دارای طول فرد را با یک بایت صفر (در صورت وجود) بپوشانید و تمام محتویات را در بلوک FORM قرار دهید. عملیات مشابهی در قالب RMID پیشنهاد شده توسط مایکروسافت استفاده می شود (نوار کناری را ببینید).