Frequently Asked Questions
оглавление | demo party в ex-СССР | infused bytes e-mag | новости от ib/news | другие проекты | письмо | win koi lat

следующий фpагмент (2)
MIDI ==== I have grabbed the code for reading and wrting variable length quantites from the spec for MIDI 0.6. I wrote some test code to verify the table of numbers found in the spec: To get your copy of the 1.0 spec, send a $2 check to: International Midi Association 5316 West 57th Street Los Angeles, CA 90056 (415) 321-MIDI Make your checks payable to the IMA. BYW, the 1.0 spec is technically identical to the .06 spec, but the description has been re-written. Since the spec has been offically approved, there shouldn't be any problem with posting this summary of the .06 spec: [This document is Dave Oppenheim's current version of the MIDI file specification, as sent to those who have participated in its development. The consensus seems to be to submit this to the MIDI Manufacturers' Association as version 1.0. I apologize for any loss of clarity that might have occurred in the conversion from a Microsoft Word document to this pure text file. I have removed some of the discussion about recent changes to the specification in order to keep the file size reasonable.--Doug Wyatt] Standard MIDI Files 0.06 March 1, 1988 0 Introduction This describes a proposed standard MIDI file format. MIDI files contain one or more MIDI streams, with time information for each event. Song, sequence, and track structures, tempo and time signature information, are all supported. Track names and other descriptive information may be stored with the MIDI data. This format supports multiple tracks and multiple sequences so that if the user of a program which supports multiple tracks intends to move a file to another one, this format can allow that to happen. This spec defines the 8-bit binary data stream used in the file. The data can be stored in a binary file, nibbleized, 7-bit-ized for efficient MIDI transmission, converted to Hex ASCII, or translated symbolically to a printable text file. This spec addresses what's in the 8-bit stream. 1 Sequences, Tracks, Chunks: File Block Structure Sequence files are made up of chunks. Each chunk has a 4-character type and a 32-bit length, which is the number of bytes in the chunk. On the Macintosh, data is passed either in the data fork of a file, or on the Clipboard. (The file type on the Macintosh for a file in this format will be "Midi".) On any other computer, the data is simply the contents of the file. This structure allows future chunk types to be designed which may easily be ignored if encountered by a program written before the chunk type is introduced. Your programs should expect alien chunks and treat them as if they weren't there. This proposal defines two types of chunks: a header chunk and a track chunk. A header chunk provides a minimal amount of information pertaining to the entire MIDI file. A track chunk contains a sequential stream of MIDI data which may contain information for up to 16 MIDI channels. The concepts of multiple tracks, multiple MIDI outputs, patterns, sequences, and songs may all be implemented using several track chunks. A MIDI file always starts with a header chunk, and is followed by one or more track chunks. MThd <length of header data> <header data> MTrk <length of track data> <track data> MTrk <length of track data> <track data> ... Track Data Format (MTrk chunk type) The MTrk chunk type is where actual song data is stored. It is simply a stream of MIDI events (and non-MIDI events), preceded by delta-time values. Some numbers in MTrk chunks are represented in a form called a variable- length quantity. These numbers are represented 7 bits per byte, most significant bits first. All bytes except the last have bit 7 set, and the last byte has bit 7 clear. If the number is between 0 and 127, it is thus represented exactly as one byte. Here are some examples of numbers represented as variable-length quantities: Number (hex) Representation (hex) 00000000 00 00000040 40 0000007F 7F 00000080 81 00 00002000 C0 00 00003FFF FF 7F 00004000 81 80 00 00100000 C0 80 00 001FFFFF FF FF 7F 00200000 81 80 80 00 08000000 C0 80 80 00 0FFFFFFF FF FF FF 7F However, when I execute my code (which prints the results in ASCII rather than binary so I can see what it does), the results are the same until we get over 128 (decimal). Why am I getting different results, the code is the same as that in the spec! Anyone else have any code for reading/writing variable length quantities? here is my code: #include <stdio.h> void WriteVarLen (register unsigned long value, FILE* fp) { register unsigned long buffer; buffer = value & 0x7f; while ( (value >>= 7) > 0) { buffer <<= 8; buffer |= 0x80; buffer += (value & 0x7f); } while (1) { //fprintf (fp, "%c", buffer); fprintf (fp, "%02x ", buffer); if (buffer & 0x80) buffer >>= 8; else break; } } double RedVarLen (FILE *fp) { register unsigned long value; register char c; if ( (value = getc(fp)) & 0x80) { value &= 0x7f; do { value = (value << 7) + ( (c = getc(fp)) & 0x7f); } while (c & 0x80); } return value; } void doit (unsigned long d) { fprintf (stdout, "\n(%x) --> ", d); WriteVarLen (d, stdout); } main(int argc, char **argv) { unsigned long x; doit (0x0ul); doit (0x40ul); doit (0x7ful); doit (0x80ul); doit (0x2000ul); doit (0x3FFFul); doit (0x4000ul); doit (0x100000ul); doit (0x1FFFFFul); doit (0x200000ul); doit (0x8000000ul); doit (0xFFFFFFFul); } - G. Bowden Wise Computer Science Department Internet: Rensselaer Polytechnic Institute Troy, NY 12180

Всего 1 фpагмент(а/ов) |пpедыдущий фpагмент (1)

Если вы хотите дополнить FAQ - пожалуйста пишите.

design/collection/some content by Frog,
DEMO DESIGN FAQ (C) Realm Of Illusion 1994-2000,
При перепечатке материалов этой страницы пожалуйста ссылайтесь на источник: "DEMO.DESIGN FAQ,".