Мультимедиялық файлдар үшін тегтелген құрылымдық формат (RIFF)
Resource Interchange File Format
RIFF форматы – мультимедия файлдары үшін тагталған контейнер. AVI, WAV, ANI сияқты форматтардың негізі. Microsoft пен IBM әзірлеген, 1991 жылдан қолданылады.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Мултимедиялық ресурстар файлдарының тегтелген файлдық құрылымы. Ресурс алмасу файл форматы (RIFF) – деректерді тегтелген кескіндерде сақтауға арналған жалпы файл контейнері форматы. Ол негізінен аудио және бейне үшін қолданылады, бірақ кез келген дерек үшін де пайдаланылуы мүмкін. Microsoft жүзеге асыруы көбінесе RIFF негізінде құрылған AVI, ANI және WAV сияқты контейнер форматтары арқылы танымал.
Tagged file structure for multimedia resource files
Resource Interchange File Format (RIFF) is a generic file container format for storing data in tagged chunks. It is primarily used for audio and video, though it can be used for arbitrary data. The Microsoft implementation is mostly known through container formats like AVI, ANI and WAV, which use RIFF as their basis.
Тарих
RIFF 1991 жылы Microsoft және IBM компанияларымен енгізілді және Windows 3.1 мультимедиялық файлдары үшін стандартты формат ретінде қолданылды. Ол 1985 жылы Amiga платформасында Electronic Arts ұсынған Interchange File Format негізінде құрылған. IFF Amiga-ның Motorola 68000 процессорының үлкен ендиандық жүйесін пайдаланады, бірақ RIFF-та көп байттық бүтін сандар IBM PC үйлесімді x86 процессорларында қолданылатын кішкентай ендиандық тәртіппен сақталады. Үлкен ендиандық формат болып табылатын RIFX форматы да енгізілді. 2010 жылы Google RIFF-ты контейнер ретінде пайдаланатын WebP сурет форматын ұсынды.
RIFF was introduced in 1991 by Microsoft and IBM and used as the default format for Windows 3.1 multimedia files. It is based on Interchange File Format introduced by Electronic Arts in 1985 on the Amiga. IFF uses the big endian convention of the Amiga's Motorola 68000 CPU, but in RIFF multi byte integers are stored in the little endian order of the x86 processors used in IBM PC compatibles. A RIFX format, which is big endian, was also introduced. In 2010 Google introduced the WebP picture format, which uses RIFF as a container.
INFO бөлігін пайдалану
INFO опциялық бөлігі RIFF файлдарын авторлық құқық ("ICOP"), түсініктемелер ("ICMT"), автор ("IART") сияқты бірнеше алдын ала белгіленген санаттарға жататын ақпаратпен стандартталған түрде "маркеулеуге" мүмкіндік береді. Бұл мәліметтерді RIFF файлынан, файлдың қалған форматы танылмаса да оқуға болады. Стандарт сонымен қатар пайдаланушы анықтаған өрістерді де қолдануға рұқсат береді. Стандартты емес өрістерді пайдалануды жоспарлаған бағдарламашылар, бірдей стандартты емес субблок ID әртүрлі бағдарламалар тарапынан әртүрлі (және мүмкін үйлеспейтін) тәсілдермен қолданылуы мүмкін екенін есте ұстауы керек.
The optional INFO chunk allows RIFF files to be "tagged" with information falling into a number of predefined categories, such as copyright ("ICOP"), comments ("ICMT"), artist ("IART"), in a standardised way. These details can be read from a RIFF file even if the rest of the file format is unrecognized. The standard also allows the use of user defined fields. Programmers intending to use non standard fields should bear in mind that the same non standard subchunk ID may be used by different applications in different (and potentially incompatible) ways.
MIDI файлдарымен бастапқы қиындықтар
Windows 3.1 "мультимедиялық" файлдардың барлығы үшін RIFF пайдалану саясатына сәйкес, Microsoft электрондық музыкалық аспаптарда ойнатылатын ән туралы ақпаратты сақтауға арналған, қазіргі қолданыстағы MIDI файл форматының жаңа түрін енгізді. Microsoft-тың MIDI файл форматы RIFF контейнеріне салынған стандартты MIDI файлдан тұрады және RMI кеңейтімді файл ретінде сақталады. Қазіргі MIDI файл форматы бұрыннан кіріктірілген "маркерлеу" ақпаратын қолдағандықтан, бір типті ақпарат үшін екі файл форматымен жұмыс істеуге тура келетін қиындық туды. Кейіннен MIDI өндірушілер қауымдастығы RIFF негізіндегі MIDI файл форматын қабылдап, оны "DLS" форматындағы аспап деректерін де қамтитын, сол RMI файлына кіріктірілген "кеңейтілген midifile" негізі ретінде пайдаланды.
In line with their policy of using RIFF for all Windows 3.1 "multimedia" files, Microsoft introduced a new variant on the existing MIDI file format used for storing song information to be played on electronic musical instruments. Microsoft's MIDI file format consisted of a standard MIDI file enclosed in a RIFF wrapper, and had the file extension RMI. Since the existing MIDI file format already supported embedded "tagging" information, this caused the disadvantage of having to deal with two file formats for the same type of information. The MIDI Manufacturers Association have since embraced the RIFF based MIDI file format, and used it as the basis of an "extended midifile" that also includes instrument data in "DLS" format, embedded within the same RMI file.
INFO бөлшектерін орналастыру проблемалары
Каталогтастыру мақсатында INFO бөлігінің оңтайлы орны файлдың басына жақын. Алайда, INFO бөлігі міндетті емес болғандықтан, ол жеке файл форматтарының егжей-тегжейлі сипаттамаларынан көбінесе алынып тасталады, бұл файл ішінде осы бөліктің дұрыс орналасуына қатысты шатасуға әкеледі. Үлкен медиа файлдармен жұмыс істегенде, тегтерді өңдеу кезінде INFO бөлігінің кеңеюі немесе қысқаруы файлдың келесі "деректер" бөлімінің жаңа бас тақырыптың мөлшеріне сәйкес келуі үшін дискке оқылып, қайта жазылуын талап етеді. Медиа файлдардың көлемі гигабайттарға жете алатындықтан, бұл дискіге үлкен жүктеме түсіретін процесс. Бір шешім – файл құрылған кезде, бос деректерді (немесе «бос бөліктерді») пайдаланып, бастапқы INFO бөлігін «толтыру». Кейінірек өңдеу кезінде файлдың жалпы мөлшерін тұрақты ұстау үшін «бос» өріс кеңейтіліп немесе қысқартылуы мүмкін: интеллектуалды бағдарламалық жасақтама тегтік деректер өзгертілгенде файлдың тек бас бөлігін жаза алады, файлдың негізгі бөлігін өзгертпей не жылжытпай. Кейбір бағдарламалар мәселені шешу үшін INFO бөлігін медиа файлдың соңына, файлдың негізгі бөлігінен кейін орналастыруға тырысты. Бұл екі түрлі келісімге әкелді, олар бағдарламалық жасақтаманың кейбір комбинациялары файлдың INFO деректерін елемеуге немесе өңдеу кезінде оларды қайта жазуға себеп болуы мүмкін. Күрделі бағдарламалар файлдардағы «күтпеген» бөліктердің орналасу мүмкіндігін ескереді және тиісінше әрекет етеді. Мысалы, аудио өңдеу бағдарламасы Audacity INFO деректері соңында орналасқан WAV файлын кездестіргенде, деректерді дұрыс анықтап, оқиды, бірақ сақтағанда INFO бөлігін файлдың басына қайта орналастырады. CorelDRAW 10 номиналды түрде RIFF файл құрылымын қолданса да, бағдарламаның бастапқы нұсқасы INFO бөлігін соңына орналастырды, сондықтан Windows файлдық басқарушысында кіріктірілген алдын ала қарау картасы әдепкі бойынша көрсетілмейді. Бағдарламамен бірге келген «жөндеу» құралы бұл мәселені шешеді.
For cataloguing purposes, the optimal position for the INFO chunk is near the beginning of the file. However, since the INFO chunk is optional, it is often omitted from the detailed specifications of individual file formats, leading to some confusion over the correct position for this chunk within a file. When dealing with large media files, the expansion or contraction of the INFO chunk during tag editing can result in the following "data" section of the file having to be read and rewritten back to disk to accommodate the new header size. Since media files can be gigabytes in size, this is a potentially disk intensive process. One workaround is to "pad out" the leading INFO chunk using dummy data (using a "dummy chunk" or "pad chunk") when the file is created. Later editing can then expand or contract the "dummy" field to keep the total size of the file header constant: an intelligently written piece of software can then overwrite just the file header when tagging data is changed, without modifying or moving the main body of the file. Some programs have tried to address the problem by placing the INFO chunk at the end of a media file, after the main body of the file. This has resulted in two different conventions for chunk placement, with the attendant risk that some combinations of software can cause a file's INFO data to be ignored or permanently overwritten during editing. More sophisticated programs will take into account the possibility of "unexpected" chunk placement in files and respond accordingly. For instance, when the audio editing program Audacity encounters a WAV file with end placed INFO data, it will correctly identify and read the data, but on saving, will relocate the INFO chunk back to the file header. Although CorelDRAW 10 nominally uses a RIFF file structure, the program's initial release placed the INFO chunk at the end, so that any embedded preview bitmap would not be displayed under Windows' file manager by default. A "patch" utility supplied with the program fixes this problem.