قسمت پنجم از مجموعه مقالاتی که پروتکل MIDI را شرح می دهد.

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

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

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

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

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

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

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

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

مقدار حافظه اولیه در ترتیب‌دهنده‌ها و ایستگاه‌های کاری سخت‌افزاری (به یاد بیاورید، یک ایستگاه کاری یک تولیدکننده آهنگ و یک ترتیب‌دهنده در یک جعبه است) معمولاً با تعداد یادداشت‌های ذخیره شده (مثلاً 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 می خواستند فشرده ترین قالب ممکن را دریافت کنند.

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

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

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

اکنون عدد 128 (0x80) است. به صورت دودویی، به صورت 1000 0000 نوشته می شود. هشت بیت مهم وجود دارد، بنابراین همه چیز در یک بایت قرار نمی گیرد، باید آن را به دو قسمت تقسیم کنید. بایت اول باید یک در بیت بالا داشته باشد، بایت دوم (به عنوان بایت نهایی سری) باید صفر داشته باشد. ما هفت بیت کم اهمیت از عدد اصلی را در بایت دوم قرار می دهیم، 0 000 0000 به دست می آید. یک بیت باقی مانده (یک) در سمت راست بایت اول قرار می گیرد - 1000 0001 می شود. در نتیجه ، عدد 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 (یا 268435455 تیک) باشد که در 500 BPM و 96 PPQN حدود چهار روز است. بیش از اندازه کافی!

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

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

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

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

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

یک فایل IFF از عناصری از همان نوع تشکیل شده است که بلوک ها (تکه ها) نامیده می شوند. بلوک یک ساختار داده ای است که از یک شناسه نامه (چهار کاراکتر اسکی)، اندازه بلوک (چهار بایت) و خود داده تشکیل شده است (شکل 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 پیشنهاد شده توسط مایکروسافت استفاده می شود (نوار کناری را ببینید).