미국비자(관광비자)를 신청하려면 가장 먼저 하셔야 할 사항은 비자정보센터 전화 003-08-131-420(월~금요일, 08:30~17:00, 유료전화)에 전화를 하셔서 인터뷰날짜를 예약하셔야 됩니다.
관광 방문, 사업상 출장의 목적으로 미국을 방문하기 위해 미국 비자를 신청할 경우 반드시 비자 인터뷰를 하셔야 합니다. 비자 인터뷰를 하기 위해서는 인터뷰 날짜를 예약하셔야 합니다. 인터뷰 날짜 는 반드시 비자 정보 인터넷 서비스 싸이트 : http://www.us-visaservices.com/ 다음 관광/상용 방문 비자신청자의 경우에는 비자 인터뷰를 할 필요가 없습니다.
단, 부모중 한명이 미국비자를 소지한 14세미만자나 80세이상자는 인터뷰를 받지 않아도 되니 인터뷰날짜를 예약하지 않아도 됩니다.
6. 재정서류 -지방세과세(납세)증명서 등 재산관련 서류 (본인이나 배우자가 직장인인 경우) - 재직증명서 원본 , 급여명세서(회사발행), 소득금액 증명원(세무서발행), 각종근로소득세 원천징수영수증 최근 1년분 : 세무 회계사 또는 회사 자체 발행 (본인이나 배우자가 사업자인 경우) - 사업자등록증, 납세 증명(납세 사실증명 최근 1년분, 세무서발행), 사업용 은행통장.소득금액증명(세무서 발행)
7. 신청일로부터 1년전까지의 은행통장 원본./거래통장 복사본 –주 거래 통장 또는 적금통장, 보험증권 등(예: 본인이나 배우자의 월급이 정기적으로 입금되는 주거래 통장)
8. 주민등록등본 또는 호적등본 : 등본상 신청인 혼자만 등재된 경우 호적등본 첨부 9. 과거 미국비자를 받은 경우, 과거 미국비자가 붙은 여권 10. 출장으로 갈 경우에는 출장증명서. 11. 학생일 경우 성적증명서 12. 대사관에서 인정하는 한국내 택배서비스 신청서. 일양 (1588-0002; http://www.ilyanglogis.com/) DHL일양(1588-0002) 한진택배(1588-0011; http://www.hanjin.co.kr/) 한진택배(1588-0011)
※ 모든 한글서류는 영어로 번역하지 않아도 됩니다.
위와 같이 서류준비가 다 되셨으면 기다리시다가 인터뷰약속날짜가 되면 준비한 모든 서류를 지참하고 (모든 비자 관련 서류는 비자 인터뷰 날짜에 신청자가 직접 지참해야 함.)주한 미국대사관에 가셔서 서류를 제출하고 인터뷰를 받으시면 됩니다.
[인터뷰 절차] 1, 자신의 예약시간보다 일찍와서 주한 미국대사관 앞에 줄을 선다
2. 대사관 입장시 보안검색을 한다.(금속탐지기 통과, 엑스레이 기계로 소지품 검사) - 휴대전화 등 반입금지물품은 출입구에 맡기고 보관표를 받아, 인터뷰 후 돌려받게 됩니다.
<<미국 대사관은요.. 지하철 5호선 광화문역 2번출구로 나오시면 쉽게 찾을 수 있습니다>>
구비서류
최소한 6개월 이상 유효하고 본인 서명이 된 여권 전자비이민 비자신청서 (DS-156)를 빠짐없이 기입, 서명하고 신청자의 사진 (사진규격 참고)을 붙여서 내십시오. 추가 비이민 비자신청서 (DS-157) 를 빠짐없이 기입하여 내십시오 신한은행 비자신청 수수료(US$ 100 에 해당하는 원화금액) 납부 영수증. 신한은행의 전국지점에서 납부 가능합니다. 대사관 근처에도 신한은행 지점이 있습니다. (약도) 부모 여권에 기재된 자녀도 미국 비자를 신청하는 경우 각 신청자별로 비자신청 수수료 납부 영수증을 제출하셔야 합니다. *신한은행 비자신청 수수료 면제에 관한 안내는 아래를 참고해 주십시오 본인이나 배우자가 봉급생활자일 경우, 재직증명서와 세무서 또는 국세청 홈택스 서비스 (www.hometax.go.kr) 에서 발행한 "소득금액 증명". 본인이나 배우자가 사업자일 경우에는 사업자등록증과 함께 본인의 사업과 소득액을 보여줄 수 있는 세금증명. 또한 본인의 사업과 소득액을 보여줄 수 있는 은행 통장 오랜 기간 동안의 재정적인 상태를 잘 보여줄 수 있는 은행통장 원본 (예: 본인이나 배우자의 월급이 정기적으로 입금되는 주거래 통장) 호적등본 학생일 경우 성적증명
The Standard MIDI File (SMF) is a file format specifically designed to store the data that a sequencer records and plays (whether that sequencer be software or hardware based).
This format stores the standard MIDI messages (ie, status bytes with appropriate data bytes) plus a time-stamp for each message (ie, a series of bytes that represent how many clock pulses to wait before "playing" the event). The format allows saving information about tempo, pulses per quarter note resolution (or resolution expressed in divisions per second, ie SMPTE setting), time and key signatures, and names of tracks and patterns. It can store multiple patterns and tracks so that any application can preserve these structures when loading the file.
NOTE: A track usually is analogous to one musical part, such as a Trumpet part. A pattern would be analogous to all of the musical parts (ie, Trumpet, Drums, Piano, etc) for a song, or excerpt of a song.
The format was designed to be generic so that any sequencer could read or write such a file without losing the most important data, and flexible enough for a particular application to store its own proprietary, "extra" data in such a way that another application won't be confused when loading the file and can safely ignore this extra stuff that it doesn't need. Think of the MIDI file format as a musical version of an ASCII text file (except that the MIDI file contains binary data too), and the various sequencer programs as text editors all capable of reading that file. But, unlike ASCII, MIDI file format saves data in chunks (ie, groups of bytes preceded by an ID and size) which can be parsed, loaded, skipped, etc. Therefore, it can be easily extended to include a program's proprietary info. For example, maybe a program wants to save a "flag byte" that indicates whether the user has turned on an audible metronome click. The program can put this flag byte into a MIDI file in such a way that another application can skip this byte without having to understand what that byte is for. In the future, the MIDI file format can also be extended to include new "official" chunks that all sequencer programs may elect to load and use. This can be done without making old data files obsolete (ie, the format is designed to be extensible in a backwardly compatible way).
What's a Chunk? Data is always saved within a chunk. There can be many chunks inside of a MIDI file. Each chunk can be a different size (ie, where size refers to how many bytes are contained in the chunk). The data bytes in a chunk are related in some way. A chunk is simply a group of related bytes.
Each chunk begins with a 4 character (ie, 4 ascii bytes) ID which tells what "type" of chunk this is. The next 4 bytes (all bytes are comprised of 8 bits) form a 32-bit length (ie, size) of the chunk. All chunks must begin with these two fields (ie, 8 bytes), which are referred to as the chunk header.
NOTE: The Length does not include the 8 byte chunk header. It simply tells you how many bytes of data are in the chunk following this header.
Here's an example header (with bytes expressed in hex):
4D 54 68 64 00 00 00 06
Note that the first 4 bytes make up the ascii ID of MThd (ie, the first four bytes are the ascii values for 'M', 'T', 'h', and 'd'). The next 4 bytes tell us that there should be 6 more data bytes in the chunk (and after that we should find the next chunk header or the end of the file).
In fact, all MIDI files begin with this MThd header (and that's how you know that it's a MIDI file).
NOTE: The 4 bytes that make up the Length are stored in Motorola 68000 byte order, not Intel reverse byte order (ie, the 06 is the fourth byte instead of the first of the four). All multiple byte fields in a MIDI file follow this standard, often called "Big Endian" form.
MThd Chunk The MThd header has an ID of MThd, and a Length of 6.
Let's examine the 6 data bytes (which follow the above, 8 byte header) in an MThd chunk.
The first two data bytes tell the Format (which I prefer to call Type). There are actually 3 different types (ie, formats) of MIDI files. A type of 0 means that the file contains one single track containing midi data on possibly all 16 midi channels. If your sequencer sorts/stores all of its midi data in one single block of memory with the data in the order that it's "played", then it should read/write this type. A type of 1 means that the file contains one or more simultaneous (ie, all start from an assumed time of 0) tracks, perhaps each on a single midi channel. Together, all of these tracks are considered one sequence or pattern. If your sequencer separates its midi data (i.e. tracks) into different blocks of memory but plays them back simultaneously (ie, as one "pattern"), it will read/write this type. A type of 2 means that the file contains one or more sequentially independant single-track patterns. f your sequencer separates its midi data into different blocks of memory, but plays only one block at a time (ie, each block is considered a different "excerpt" or "song"), then it will read/write this type.
The next 2 bytes tell how many tracks are stored in the file, NumTracks. Of course, for format type 0, this is always 1. For the other 2 types, there can be numerous tracks.
The last two bytes indicate how many Pulses (i.e. clocks) Per Quarter Note (abbreviated as PPQN) resolution the time-stamps are based upon, Division. For example, if your sequencer has 96 ppqn, this field would be (in hex):
00 60
Alternately, if the first byte of Division is negative, then this represents the division of a second that the time-stamps are based upon. The first byte will be -24, -25, -29, or -30, corresponding to the 4 SMPTE standards representing frames per second. The second byte (a positive number) is the resolution within a frame (ie, subframe). Typical values may be 4 (MIDI Time Code), 8, 10, 80 (SMPTE bit resolution), or 100.
You can specify millisecond-based timing by the data bytes of -25 and 40 subframes.
Here's an example of a complete MThd chunk (with header):
4D 54 68 64 MThd ID 00 00 00 06 Length of the MThd chunk is always 6. 00 01 The Format type is 1. 00 02 There are 2 MTrk chunks in this file. E7 28 Each increment of delta-time represents a millisecond.
MTrk Chunk After the MThd chunk, you should find an MTrk chunk, as this is the only other currently defined chunk. (If you find some other chunk ID, it must be proprietary to some other program, so skip it by ignoring the following data bytes indicated by the chunk's Length).
An MTrk chunk contains all of the midi data (with timing bytes), plus optional non-midi data for one track. Obviously, you should encounter as many MTrk chunks in the file as the MThd chunk's NumTracks field indicated.
The MTrk header begins with the ID of MTrk, followed by the Length (ie, number of data bytes to read for this track). The Length will likely be different for each track. (After all, a track containing the violin part for a Bach concerto will likely contain more data than a track containing a simple 2 bar drum beat).
Variable Length Quantities -- Event's Time Think of a track in the MIDI file in the same way that you normally think of a track in a sequencer. A sequencer track contains a series of events. For example, the first event in the track may be to sound a middle C note. The second event may be to sound the E above middle C. These two events may both happen at the same time. The third event may be to release the middle C note. This event may happen a few musical beats after the first two events (ie, the middle C note is held down for a few musical beats). Each event has a "time" when it must occur, and the events are arranged within a "chunk" of memory in the order that they occur.
In a MIDI file, an event's "time" precedes the data bytes that make up that event itself. In other words, the bytes that make up the event's time-stamp come first. A given event's time-stamp is referenced from the previous event. For example, if the first event occurs 4 clocks after the start of play, then its "delta-time" is 04. If the next event occurs simultaneously with that first event, its time is 00. So, a delta-time is the duration (in clocks) between an event and the preceding event.
NOTE: Since all tracks start with an assumed time of 0, the first event's delta-time is referenced from 0.
A delta-time is stored as a series of bytes which is called a variable length quantity. Only the first 7 bits of each byte is significant (right-justified; sort of like an ASCII byte). So, if you have a 32-bit delta-time, you have to unpack it into a series of 7-bit bytes (ie, as if you were going to transmit it over midi in a SYSEX message). Of course, you will have a variable number of bytes depending upon your delta-time. To indicate which is the last byte of the series, you leave bit #7 clear. In all of the preceding bytes, you set bit #7. So, if a delta-time is between 0-127, it can be represented as one byte. The largest delta-time allowed is 0FFFFFFF, which translates to 4 bytes variable length. Here are examples of delta-times as 32-bit values, and the variable length quantities that they translate to:
Here's some C routines to read and write variable length quantities such as delta-times. With WriteVarLen(), you pass a 32-bit value (ie, unsigned long) and it spits out the correct series of bytes to a file. ReadVarLen() reads a series of bytes from a file until it reaches the last byte of a variable length quantity, and returns a 32-bit value. void WriteVarLen(register unsigned long value) { register unsigned long buffer; buffer = value & 0x7F;
if ( (value = getc(infile)) & 0x80 ) { value &= 0x7F; do { value = (value << 7) + ((c = getc(infile)) & 0x7F); } while (c & 0x80); }
return(value); }
NOTE: The concept of variable length quantities (ie, breaking up a large value into a series of bytes) is used with other fields in a MIDI file besides delta-times, as you'll see later.
Events The first (1 to 4) byte(s) in an MTrk will be the first event's delta-time as a variable length quantity. The next data byte is actually the first byte of that event itself. I'll refer to this as the event's Status. For MIDI events, this will be the actual MIDI Status byte (or the first midi data byte if running status). For example, if the byte is hex 90, then this event is a Note-On upon midi channel 0. If for example, the byte was hex 23, you'd have to recall the previous event's status (ie, midi running status). Obviously, the first MIDI event in the MTrk must have a status byte. After a midi status byte comes its 1 or 2 data bytes (depending upon the status - some MIDI messages only have 1 subsequent data byte). After that you'll find the next event's delta time (as a variable quantity) and start the process of reading that next event.
SYSEX (system exclusive) events (status = F0) are a special case because a SYSEX event can be any length. After the F0 status (which is always stored -- no running status here), you'll find yet another series of variable length bytes. Combine them with ReadVarLen() and you'll come up with a 32-bit value that tells you how many more bytes follow which make up this SYSEX event. This length doesn't include the F0 status.
For example, consider the following SYSEX MIDI message:
F0 7F 7F 04 01 7F 7F F7
This would be stored in a MIDI file as the following series of bytes (minus the delta-time bytes which would precede it):
F0 07 7F 7F 04 01 7F 7F F7
Some midi units send a system exclusive message as a series of small "packets" (with a time delay inbetween transmission of each packet). The first packet begins with an F0, but it doesn't end with an F7. The subsequent packets don't start with an F0 nor end with F7. The last packet doesn't start with an F0, but does end with the F7. So, between the first packet's opening F0 and the last packet's closing F7, there's 1 SYSEX message there. (Note: only extremely poor designs, such as the crap marketed by Casio exhibit these aberrations). Of course, since a delay is needed inbetween each packet, you need to store each packet as a separate event with its own time in the MTrk. Also, you need some way of knowing which events shouldn't begin with an F0 (ie, all of them except the first packet). So, the MIDI file spec redefines a midi status of F7 (normally used as an end mark for SYSEX packets) as a way to indicate an event that doesn't begin with F0. If such an event follows an F0 event, then it's assumed that the F7 event is the second "packet" of a series. In this context, it's referred to as a SYSEX CONTINUATION event. Just like the F0 type of event, it has a variable length followed by data bytes. On the other hand, the F7 event could be used to store MIDI REALTIME or MIDI COMMON messages. In this case, after the variable length bytes, you should expect to find a MIDI Status byte of F1, F2, F3, F6, F8, FA, FB, FC, or FE. (Note that you wouldn't find any such bytes inside of a SYSEX CONTINUATION event). When used in this manner, the F7 event is referred to as an ESCAPED event.
A status of FF is reserved to indicate a special non-MIDI event. (Note that FF is used in MIDI to mean "reset", so it wouldn't be all that useful to store in a data file. Therefore, the MIDI file spec arbitrarily redefines the use of this status). After the FF status byte is another byte that tells you what Type of non-MIDI event it is. It's sort of like a second status byte. Then after this byte is another byte(s -- a variable length quantity again) that tells how many more data bytes follow in this event (ie, its Length). This Length doesn't include the FF, Type byte, nor the Length byte. These special, non-MIDI events are called Meta-Events, and most are optional unless otherwise noted. What follows are some defined Meta-Events (including the FF Status and Length). Note that unless otherwise mentioned, more than one of these events can be placed in an Mtrk (even the same Meta-Event) at any delta-time. (Just like all midi events, Meta-Events have a delta-time from the previous event regardless of what type of event that may be. So, you can freely intermix MIDI and Meta events).
Sequence Number FF 00 02 ss ss
This optional event which must occur at the beginning of a MTrk (ie, before any non-zero delta-times and before any midi events) specifies the number of a sequence. The two data bytes ss ss, are that number which corresponds to the MIDI Cue message. In a format 2 MIDI file, this number identifies each "pattern" (ie, Mtrk) so that a "song" sequence can use the MIDI Cue message to refer to patterns. If the ss ss numbers are omitted (ie, Length byte = 0 instead of 2), then the MTrk's location in the file is used (ie, the first MTrk chunk is the first pattern). In format 0 or 1, which contain only one "pattern" (even though format 1 contains several MTrks), this event is placed in only the first MTrk. So, a group of format 1 files with different sequence numbers can comprise a "song collection".
There can be only one of these events per MTrk chunk in a Format 2. There can be only one of these events in a Format 0 or 1, and it must be in the first MTrk.
Text FF 01 len text
Any amount of text (amount of bytes = len) for any purpose. It's best to put this event at the beginning of an MTrk. Although this text could be used for any purpose, there are other text-based Meta-Events for such things as orchestration, lyrics, track name, etc. This event is primarily used to add "comments" to a MIDI file which a program would be expected to ignore when loading that file.
Note that len could be a series of bytes since it is expressed as a variable length quantity.
Copyright FF 02 len text
A copyright message (ie, text). It's best to put this event at the beginning of an MTrk.
Note that len could be a series of bytes since it is expressed as a variable length quantity.
Sequence/Track Name FF 03 len text
The name of the sequence or track (ie, text). It's best to put this event at the beginning of an MTrk.
Note that len could be a series of bytes since it is expressed as a variable length quantity.
Instrument FF 04 len text
The name of the instrument that the track plays (ie, text). This might be different than the Sequence/Track Name. For example, maybe the name of your sequence (ie, Mtrk) is "Butterfly", but since the track is played on a piano, you might also include an Instrument Name of "Piano".
It's best to put one (or more) of this event at the beginning of an MTrk to provide the user with identification of what instrument(s) is playing the track. Usually, the instruments (ie, patches, tones, banks, etc) are setup on the audio devices via MIDI Program Change events within the MTrk, particularly in MIDI files that are intended for General MIDI Sound Modules. So, this event exists merely to provide the user with visual feedback of the instrumentation for a track.
Note that len could be a series of bytes since it is expressed as a variable length quantity.
Lyric FF 05 len text
A song lyric (ie, text) which occurs on a given beat. A single Lyric MetaEvent should contain only one syllable.
Note that len could be a series of bytes since it is expressed as a variable length quantity.
Marker FF 06 len text
A marker (ie, text) which occurs on a given beat. Marker events might be used to denote a loop start and loop end (ie, where the sequence loops back to a previous event).
Note that len could be a series of bytes since it is expressed as a variable length quantity.
Cue Point FF 07 len text
A cue point (ie, text) which occurs on a given beat. A Cue Point might be used to denote where a WAVE (ie, sampled sound) file starts playing, where the text would be the WAVE's filename.
Note that len could be a series of bytes since it is expressed as a variable length quantity.
MIDI Channel FF 20 01 cc
This optional event which normally occurs at the beginning of an MTrk (ie, before any non-zero delta-times and before any MetaEvents except Sequence Number) specifies to which MIDI Channel any subsequent MetaEvent or System Exclusive events are associated. The data byte cc, is the MIDI channel, where 0 would be the first channel.
The MIDI spec does not give a MIDI channel to System Exclusive events. Nor do MetaEvents have an imbedded channel. When creating a Format 0 MIDI file, all of the System Exclusive and MetaEvents go into one track, so its hard to associate these events with respective MIDI Voice messages. (ie, For example, if you wanted to name the musical part on MIDI channel 1 "Flute Solo", and the part on MIDI Channel 2 "Trumpet Solo", you'd need to use 2 Track Name MetaEvents. Since both events would be in the one track of a Format 0 file, in order to distinguish which track name was associated with which MIDI channel, you would place a MIDI Channel MetaEvent with a channel number of 0 before the "Flute Solo" Track Name MetaEvent, and then place another MIDI Channel MetaEvent with a channel number of 1 before the "Trumpet Solo" Track Name MetaEvent.
It is acceptable to have more than one MIDI channel event in a given track, if that track needs to associate various events with various channels.
MIDI Port FF 21 01 pp
This optional event which normally occurs at the beginning of an MTrk (ie, before any non-zero delta-times and before any midi events) specifies out of which MIDI Port (ie, buss) the MIDI events in the MTrk go. The data byte pp, is the port number, where 0 would be the first MIDI buss in the system.
The MIDI spec has a limit of 16 MIDI channels per MIDI input/output (ie, port, buss, jack, or whatever terminology you use to describe the hardware for a single MIDI input/output). The MIDI channel number for a given event is encoded into the lowest 4 bits of the event's Status byte. Therefore, the channel number is always 0 to 15. Many MIDI interfaces have multiple MIDI input/output busses in order to work around limitations in the MIDI bandwidth (ie, allow the MIDI data to be sent/received more efficiently to/from several external modules), and to give the musician more than 16 MIDI Channels. Also, some sequencers support more than one MIDI interface used for simultaneous input/output. Unfortunately, there is no way to encode more than 16 MIDI channels into a MIDI status byte, so a method was needed to identify events that would be output on, for example, channel 1 of the second MIDI port versus channel 1 of the first MIDI port. This MetaEvent allows a sequencer to identify which MTrk events get sent out of which MIDI port. The MIDI events following a MIDI Port MetaEvent get sent out that specified port.
It is acceptable to have more than one Port event in a given track, if that track needs to output to another port at some point in the track.
End of Track FF 2F 00
This event is NOT optional. It must be the last event in every MTrk. It's used as a definitive marking of the end of an MTrk. Only 1 per MTrk.
Tempo FF 51 03 tt tt tt
Indicates a tempo change. The 3 data bytes of tt tt tt are the tempo in microseconds per quarter note. In other words, the microsecond tempo value tells you how long each one of your sequencer's "quarter notes" should be. For example, if you have the 3 bytes of 07 A1 20, then each quarter note should be 0x07A120 (or 500,000) microseconds long.
So, the MIDI file format expresses tempo as "the amount of time (ie, microseconds) per quarter note".
BPM Normally, musicians express tempo as "the amount of quarter notes in every minute (ie, time period)". This is the opposite of the way that the MIDI file format expresses it. When musicians refer to a "beat" in terms of tempo, they are referring to a quarter note (ie, a quarter note is always 1 beat when talking about tempo, regardless of the time signature. Yes, it's a bit confusing to non-musicians that the time signature's "beat" may not be the same thing as the tempo's "beat" -- it won't be unless the time signature's beat also happens to be a quarter note. But that's the traditional definition of BPM tempo). To a musician, tempo is therefore always "how many quarter notes happen during every minute". Musicians refer to this measurement as BPM (ie, Beats Per Minute). So a tempo of 100 BPM means that a musician must be able to play 100 steady quarter notes, one right after the other, in one minute. That's how "fast" the "musical tempo" is at 100 BPM. It's very important that you understand the concept of how a musician expresses "musical tempo" (ie, BPM) in order to properly present tempo settings to a musician, and yet be able to relate it to how the MIDI file format expresses tempo.
To convert the MIDI file format's tempo (ie, the 3 bytes that specify the amount of microseconds per quarter note) to BPM:
BPM = 60,000,000/(tt tt tt)
For example, a tempo of 120 BPM = 07 A1 20 microseconds per quarter note.
So why does the MIDI file format use "time per quarter note" instead of "quarter notes per time" to specify its tempo? Well, its easier to specify more precise tempos with the former. With BPM, sometimes you have to deal with fractional tempos (for example, 100.3 BPM) if you want to allow a finer resolution to the tempo. Using microseconds to express tempo offers plenty of resolution.
Also, SMPTE is a time-based protocol (ie, it's based upon seconds, minutes, and hours, rather than a musical tempo). Therefore it's easier to relate the MIDI file's tempo to SMPTE timing if you express it as microseconds. Many musical devices now use SMPTE to sync their playback.
PPQN Clock A sequencer typically uses some internal hardware timer counting off steady time (ie, microseconds perhaps) to generate a software "PPQN clock" that counts off the timebase (Division) "ticks". In this way, the time upon which an event occurs can be expressed to the musician in terms of a musical bar:beat:PPQN-tick rather than how many microseconds from the start of the playback. Remember that musicians always think in terms of a beat, not the passage of seconds, minutes, etc. As mentioned, the microsecond tempo value tells you how long each one of your sequencer's "quarter notes" should be. From here, you can figure out how long each one of your sequencer's PPQN clocks should be by dividing that microsecond value by your MIDI file's Division. For example, if your MIDI file's Division is 96 PPQN, then that means that each of your sequencer's PPQN clock ticks at the above tempo should be 500,000 / 96 (or 5,208.3) microseconds long (ie, there should be 5,208.3 microseconds inbetween each PPQN clock tick in order to yield a tempo of 120 BPM at 96 PPQN. And there should always be 96 of these clock ticks in each quarter note, 48 ticks in each eighth note, 24 ticks in each sixteenth, etc).
Note that you can have any timebase at any tempo. For example, you can have a 96 PPQN file playing at 100 BPM just as you can have a 192 PPQN file playing at 100 BPM. You can also have a 96 PPQN file playing at either 100 BPM or 120 BPM. Timebase and tempo are two entirely separate quantities. Of course, they both are needed when you setup your hardware timer (ie, when you set how many microseconds are in each PPQN tick). And of course, at slower tempos, your PPQN clock tick is going to be longer than at faster tempos.
MIDI Clock MIDI clock bytes are sent over MIDI, in order to sync the playback of 2 devices (ie, one device is generating MIDI clocks at its current tempo which it internally counts off, and the other device is syncing its playback to the receipt of these bytes). Unlike with SMPTE frames, MIDI clock bytes are sent at a rate related to the musical tempo. Since there are 24 MIDI Clocks in every quarter note, the length of a MIDI Clock (ie, time inbetween each MIDI Clock message) is the microsecond tempo divided by 24. In the above example, that would be 500,000/24, or 20,833.3 microseconds in every MIDI Clock. Alternately, you can relate this to your timebase (ie, PPQN clock). If you have 96 PPQN, then that means that a MIDI Clock byte must occur every 96 / 24 (ie, 4) PPQN clocks.
SMPTE SMPTE counts off the passage of time in terms of seconds, minutes, and hours (ie, the way that non-musicians count time). It also breaks down the seconds into smaller units called "frames". The movie industry created SMPTE, and they adopted 4 different frame rates. You can divide a second into 24, 25, 29, or 30 frames. Later on, even finer resolution was needed by musical devices, and so each frame was broken down into "subframes". So, SMPTE is not directly related to musical tempo. SMPTE time doesn't vary with "musical tempo".
Many devices use SMPTE to sync their playback. If you need to sychronize with such a device, then you may need to deal with SMPTE timing. Of course, you're probably still going to have to maintain some sort of PPQN clock, based upon the passing SMPTE subframes, so that the user can adjust the tempo of the playback in terms of BPM, and can consider the time of each event in terms of bar:beat:tick. But since SMPTE doesn't directly relate to musical tempo, you have to interpolate (ie, calculate) your PPQN clocks from the passing of subframes/frames/seconds/minutes/hours (just as we previously calculated the PPQN clock from a hardware timer counting off microseconds).
Let's take the easy example of 25 Frames and 40 SubFrames. As previously mentioned in the discussion of Division, this is analogous to millisecond based timing because you have 1,000 SMPTE subframes per second. (You have 25 frames per second. Each second is divided up into 40 subframes, and you therefore have 25 * 40 subframes per second. And remember that 1,000 milliseconds are also in every second). Every millisecond therefore means that another subframe has passed (and vice versa). Every time you count off 40 subframes, a SMPTE frame has passed (and vice versa). Etc.
Let's assume you desire 96 PPQN and a tempo of 500,000 microseconds. Considering that with 25-40 Frame-SubFrame SMPTE timing 1 millisecond = 1 subframe (and remember that 1 millisecond = 1,000 microseconds), there should be 500,000 / 1,000 (ie, 500) subframes per quarter note. Since you have 96 PPQN in every quarter note, then every PPQN ends up being 500 / 96 subframes long, or 5.2083 milliseconds (ie, there's how we end up with that 5,208.3 microseconds PPQN clock tick just as we did above in discussing PPQN clock). And since 1 millisecond = 1 subframe, every PPQN clock tick also equals 5.2083 subframes at the above tempo and timebase.
Designates the SMPTE start time (hours, minutes, secs, frames, subframes) of the MTrk. It should be at the start of the MTrk. The hour should not be encoded with the SMPTE format as it is in MIDI Time Code. In a format 1 file, the SMPTE OFFSET must be stored with the tempo map (ie, the first MTrk), and has no meaning in any other MTrk. The ff field contains fractional frames in 100ths of a frame, even in SMPTE based MTrks which specify a different frame subdivision for delta-times (ie, different from the subframe setting in the MThd).
Time Signature FF 58 04 nn dd cc bb
Time signature is expressed as 4 numbers. nn and dd represent the "numerator" and "denominator" of the signature as notated on sheet music. The denominator is a negative power of 2: 2 = quarter note, 3 = eighth, etc. The cc expresses the number of MIDI clocks in a metronome click. The bb parameter expresses the number of notated 32nd notes in a MIDI quarter note (24 MIDI clocks). This event allows a program to relate what MIDI thinks of as a quarter, to something entirely different. For example, 6/8 time with a metronome click every 3 eighth notes and 24 clocks per quarter note would be the following event:
FF 58 04 06 03 18 08
Key Signature FF 59 02 sf mi
sf = -7 for 7 flats, -1 for 1 flat, etc, 0 for key of c, 1 for 1 sharp, etc.
mi = 0 for major, 1 for minor
Proprietary Event FF 7F len data...
This can be used by a program to store proprietary data. The first byte(s) should be a unique ID of some sort so that a program can identity whether the event belongs to it, or to some other program. A 4 character (ie, ascii) ID is recommended for such.
Note that len could be a series of bytes since it is expressed as a variable length quantity.
Errata In a format 0 file, the tempo and time signature changes are scattered throughout the one MTrk. In format 1, the very first MTrk should consist of just the tempo and time signature events so that it could be read by some device capable of generating a "tempo map". In format 2, each MTrk should begin with at least one initial tempo and time signature event.
NOTE: If there are no tempo and time signature events in a MIDI file, assume 120 BPM and 4/4.
RMID Files The method of saving data in chunks (ie, where the data is preceded by an 8 byte header consisting of a 4 char ID and a 32-bit size field) is the basis for Interchange File Format. You should now read the article About Interchange File Format for background information.
As mentioned, MIDI File format is a "broken" IFF. It lacks a file header at the start of the file. One bad thing about this is that a standard IFF parsing routine will choke on a MIDI file (because it will expect the first 12 bytes to be the group ID, filesize, and type ID fields). In order to fix the MIDI File format so that it strictly adheres to IFF, Microsoft simply made up a 12-byte header that is prepended to MIDI files, and thereby came up with the RMID format. An RMID file begins with the group ID (4 ascii chars) of 'R', 'I', 'F', 'F', followed by the 32-bit filesize field, and then the type ID of 'R', 'M', 'I', 'D'. Then, the chunks of a MIDI file follow (ie, the MThd and MTrk chunks). If you chop off the first 12 bytes of an RMID file, then you end up with a standard MIDI file.
Note that chunks within a MIDI file are not padded out (with an extra 0 byte) to an even number of bytes. I don't know as if the RMID format corrects this aberration of the MIDI file format too.
Several bit rates are specified in the MPEG-1 Layer 3 standard: 32, 40, 48, 56, 64, 80, 96, 112, 128, 144, 160, 192, 224, 256 and 320 kbit/s, and the available sampling frequencies are 32, 44.1 and 48 kHz. A sample rate of 44.1 kHz is almost always used since this is also used for CD audio, the main source used for creating MP3 files. A greater variety of bit rates are used on the Internet. 128 kbit/s is the most common since it typically offers very good audio quality in a relatively small space. 192 kbit/s is often used by those who notice artifacts at lower bit rates. As the Internet bandwidth availability and hard drive sizes have increased, 128 kbit/s bitrate files are slowly being replaced with higher bitrates like 192 kbit/s, with some being encoded up to MP3's maximum of 320 kbit/s. It is unlikely that higher bit rates will be popular with any lossy audio codec as higher bit rates than 320 kbit/s encroach on the domain of lossless codecs such as FLAC.
By contrast, uncompressed audio as stored on a compact disc has a bit rate of 1,411.2 kbit/s (16 bits/sample × 44100 samples/second × 2 channels / 1000 bits/kilobit).
Some additional bit rates and sample rates were made available in the MPEG-2 and the (unofficial) MPEG-2.5 standards: bit rates of 8, 16, 24, and 144 kbit/s and sample rates of 8, 11.025, 12, 16, 22.05 and 24 kHz.
Non-standard bit rates up to 640 kbit/s can be achieved with the LAME encoder and the freeformat option, but few MP3 players can play those files. Gabriel Bouvigne, a principal developer of the LAME project, says that the freeformat option is compliant with the standard but, according to the standard, decoders are only required to be able to decode streams up to 320 kbit/s.[10]
File structure
An MP3 file is made up of multiple MP3 frames, which consist of the MP3 header and the MP3 data. This sequence of frames is called an Elementary stream. Frames are independent items: one can cut the frames from a file and an MP3 player would be able to play it. The MP3 data is the actual audio payload. The diagram shows that the MP3 header consists of a sync word, which is used to identify the beginning of a valid frame. This is followed by a bit indicating that this is the MPEG standard and two bits that indicate that layer 3 is being used, hence MPEG-1 Audio Layer 3 or MP3. After this, the values will differ depending on the MP3 file. ISO/IEC 11172-3 defines the range of values for each section of the header along with the specification of the header. Most MP3 files today contain ID3metadata, which precedes or follows the MP3 frames; this is also shown in the diagram.
The TAG is used to describe the MPEG Audio file. It contains information about artist, title, album, publishing year and genre. There is some extra space for comments. It is exactly 128 bytes long and is located at very end of the audio data. You can get it by reading the last 128 bytes of the MPEG audio file.
Tag identification. Must contain 'TAG' if tag exists and is correct.
B
30
(3-32)
Title
C
30
(33-62)
Artist
D
30
(63-92)
Album
E
4
(93-96)
Year
F
30
(97-126)
Comment
G
1
(127)
Genre
The specification asks for all fields to be padded with null character (ASCII 0). However, not all applications respect this (an example is WinAmp which pads fields with <space>, ASCII 32).
There is a small change proposed in ID3v1.1 structure. The last byte of the Comment field may be used to specify the track number of a song in an album. It should contain a null character (ASCII 0) if the information is unknown.
Genre is a numeric field which may have one of the following values:
The TAG is used to describe the MPEG Audio file. It contains information about artist, title, album, publishing year and genre. There is some extra space for comments. It is exactly 128 bytes long and is located at very end of the audio data. You can get it by reading the last 128 bytes of the MPEG audio file.
Tag identification. Must contain 'TAG' if tag exists and is correct.
B
30
(3-32)
Title
C
30
(33-62)
Artist
D
30
(63-92)
Album
E
4
(93-96)
Year
F
30
(97-126)
Comment
G
1
(127)
Genre
The specification asks for all fields to be padded with null character (ASCII 0). However, not all applications respect this (an example is WinAmp which pads fields with <space>, ASCII 32).
There is a small change proposed in ID3v1.1 structure. The last byte of the Comment field may be used to specify the track number of a song in an album. It should contain a null character (ASCII 0) if the information is unknown.
Genre is a numeric field which may have one of the following values:
An MPEG audio file is built up from smaller parts called frames. Generally, frames are independent items. Each frame has its own header and audio informations. There is no file header. Therefore, you can cut any part of MPEG file and play it correctly (this should be done on frame boundaries but most applications will handle incorrect headers). For Layer III, this is not 100% correct. Due to internal data organization in MPEG version 1 Layer III files, frames are often dependent of each other and they cannot be cut off just like that.
When you want to read info about an MPEG file, it is usually enough to find the first frame, read its header and assume that the other frames are the same This may not be always the case. Variable bitrate MPEG files may use so called bitrate switching, which means that bitrate changes according to the content of each frame. This way lower bitrates may be used in frames where it will not reduce sound quality. This allows making better compression while keeping high quality of sound.
The frame header is constituted by the very first four bytes (32bits) in a frame. The first eleven bits (or first twelve bits, see below about frame sync) of a frame header are always set and they are called "frame sync". Therefore, you can search through the file for the first occurence of frame sync (meaning that you have to find a byte with a value of 255, and followed by a byte with its three (or four) most significant bits set). Then you read the whole header and check if the values are correct. You will see in the following table the exact meaning of each bit in the header, and which values may be checked for validity. Each value that is specified as reserved, invalid, bad, or not allowed should indicate an invalid header. Remember, this is not enough, frame sync can be easily (and very frequently) found in any binary file. Also it is likely that MPEG file contains garbage on it's beginning which also may contain false sync. Thus, you have to check two or more frames in a row to assure you are really dealing with MPEG audio file.
Frames may have a CRC check. The CRC is 16 bits long and, if it exists, it follows the frame header. After the CRC comes the audio data. You may calculate the length of the frame and use it if you need to read other headers too or just want to calculate the CRC of the frame, to compare it with the one you read from the file. This is actually a very good method to check the MPEG header validity.
Here is "graphical" presentation of the header content. Characters from A to M are used to indicate different fields. In the table, you can see details about the content of each field.
AAAAAAAA AAABBCCD EEEEFFGH IIJJKLMM
Sign
Length (bits)
Position (bits)
Description
A
11
(31-21)
Frame sync (all bits set)
B
2
(20,19)
MPEG Audio version ID 00 - MPEG Version 2.5 01 - reserved 10 - MPEG Version 2 (ISO/IEC 13818-3) 11 - MPEG Version 1 (ISO/IEC 11172-3)
Note: MPEG Version 2.5 is not official standard. Bit No 20 in frame header is used to indicate version 2.5. Applications that do not support this MPEG version expect this bit always to be set, meaning that frame sync (A) is twelve bits long, not eleve as stated here. Accordingly, B is one bit long (represents only bit No 19). I recommend using methodology presented here, since this allows you to distinguish all three versions and keep full compatibility.
C
2
(18,17)
Layer description 00 - reserved 01 - Layer III 10 - Layer II 11 - Layer I
D
1
(16)
Protection bit 0 - Protected by CRC (16bit crc follows header) 1 - Not protected
E
4
(15,12)
Bitrate index
bits
V1,L1
V1,L2
V1,L3
V2,L1
V2, L2 & L3
0000
free
free
free
free
free
0001
32
32
32
32
8
0010
64
48
40
48
16
0011
96
56
48
56
24
0100
128
64
56
64
32
0101
160
80
64
80
40
0110
192
96
80
96
48
0111
224
112
96
112
56
1000
256
128
112
128
64
1001
288
160
128
144
80
1010
320
192
160
160
96
1011
352
224
192
176
112
1100
384
256
224
192
128
1101
416
320
256
224
144
1110
448
384
320
256
160
1111
bad
bad
bad
bad
bad
NOTES: All values are in kbps V1 - MPEG Version 1 V2 - MPEG Version 2 and Version 2.5 L1 - Layer I L2 - Layer II L3 - Layer III "free" means free format. If the correct fixed bitrate (such files cannot use variable bitrate) is different than those presented in upper table it must be determined by the application. This may be implemented only for internal purposes since third party applications have no means to find out correct bitrate. Howewer, this is not impossible to do but demands lot's of efforts. "bad" means that this is not an allowed value
MPEG files may have variable bitrate (VBR). This means that bitrate in the file may change. I have learned about two used methods:
bitrate switching. Each frame may be created with different bitrate. It may be used in all layers. Layer III decoders must support this method. Layer I & II decoders may support it.
bit reservoir. Bitrate may be borrowed (within limits) from previous frames in order to provide more bits to demanding parts of the input signal. This causes, however, that the frames are no longer independent, which means you should not cut this files. This is supported only in Layer III.
For Layer II there are some combinations of bitrate and mode which are not allowed. Here is a list of allowed combinations.
bitrate
allowed modes
free
all
32
single channel
48
single channel
56
single channel
64
all
80
single channel
96
all
112
all
128
all
160
all
192
all
224
stereo, intensity stereo, dual channel
256
stereo, intensity stereo, dual channel
320
stereo, intensity stereo, dual channel
384
stereo, intensity stereo, dual channel
F
2
(11,10)
Sampling rate frequency index (values are in Hz)
bits
MPEG1
MPEG2
MPEG2.5
00
44100
22050
11025
01
48000
24000
12000
10
32000
16000
8000
11
reserv.
reserv.
reserv.
G
1
(9)
Padding bit 0 - frame is not padded 1 - frame is padded with one extra slot Padding is used to fit the bit rates exactly. For an example: 128k 44.1kHz layer II uses a lot of 418 bytes and some of 417 bytes long frames to get the exact 128k bitrate. For Layer I slot is 32 bits long, for Layer II and Layer III slot is 8 bits long.
How to calculate frame length
First, let's distinguish two terms frame size and frame length. Frame size is the number of samples contained in a frame. It is constant and always 384 samples for Layer I and 1152 samples for Layer II and Layer III. Frame length is length of a frame when compressed. It is calculated in slots. One slot is 4 bytes long for Layer I, and one byte long for Layer II and Layer III. When you are reading MPEG file you must calculate this to be able to find each consecutive frame. Remember, frame length may change from frame to frame due to padding or bitrate switching.
Read the BitRate, SampleRate and Padding of the frame header.
Mode extension is used to join informations that are of no use for stereo effect, thus reducing needed resources. These bits are dynamically determined by an encoder in Joint stereo mode.
Complete frequency range of MPEG file is divided in subbands There are 32 subbands. For Layer I & II these two bits determine frequency range (bands) where intensity stereo is applied. For Layer III these two bits determine which type of joint stereo is used (intensity stereo or m/s stereo). Frequency range is determined within decompression algorythm.
Layer I and II
Layer III
value
Layer I & II
00
bands 4 to 31
01
bands 8 to 31
10
bands 12 to 31
11
bands 16 to 31
Intensity stereo
MS stereo
off
off
on
off
off
on
on
on
K
1
(3)
Copyright 0 - Audio is not copyrighted 1 - Audio is copyrighted
L
1
(2)
Original 0 - Copy of original media 1 - Original media
SD램(Synchronous DRAM)은 동기식 D램이라고 한다. 작동 클럭이 시스템 버스(FSB)와 똑같이 움직여서 ‘동기’라는 이름을 붙였다. SD램에는 ‘PC100 SD램’과 ‘PC133 SD램’이 있다. ‘PC133 SD램’은 시스템 버스 133MHz와 맞춰서 133MHz로 작동하는 SD램이고 ‘PC100 SD램’은 시스템 버스 100MHz와 같이 100MHz로 작동한다. 이것은 CPU와 SD램이 서로 같은 장단을 맞춘다는 말이다. CPU가 작동할 때 D램도 따라 움직여서 속도를 크게 올릴 수 있다. 처음에 나온 SD램은 속도가 대부분 10∼12나노초였다. 이것은 시스템 버스 66MHz에 알맞은 속도로서 펜티엄 III가 쓰는 시스템 버스 100MHz와 133MHz에 맞추기에는 부족했다. 때문에 속도를 한껏 끌어올리려고 SPD(serial presence detect) 칩을 모듈에 달아서 제원, 속도, 용량 등을 곧바로 알려준다. PC가 램을 알아차리는 시간을 줄여서 시스템 버스 100MHz와 133MHz에 맞춰서 작동하게 만든 것이다. SD램은 클럭이 오르고 내리는 원리를 응용해서 데이터를 주고받는다. 클럭이 아래에서 위로 올라갈 때 데이터를 내보내거나 담는다.
DDR RAM
D램을 만드는 기술이 아무리 발전해도 D램 구조의 한계 때문에 속도를 크게 높이기는 어렵다. 펜티엄 4의 시스템 버스 400MHz에 SD램 속도를 끌어올려 맞추려면 어림없다는 말이다. 때문에 클럭(MHz)을 올리기보다는 다른 방법을 써서 속도를 높이는 방법을 연구해서 만든 것이 DDR SD램이다. DDR(Double Date Rate)은 주기 한번에 작동하는 데이터 양이 두 배라는 뜻이다. SD램과 같은 속도라도 한 번에 보내는 양이 두 배이기 때문에 클럭을 높인 것과 같은 효과를 본다. 100MHz로 작동하는 DDR SD램은 200MHz로 작동하는 SD램과 같은 셈이다. DDR SD램은 SD램과 같은 명령어를 쓴다. 램에 데이터를 쓰고 읽는 원리가 같다는 이야기다. D램이 작동하는 움직임은 사인 곡선(sine curve)과 같다. 사인 곡선은 한 사이클에 한 번은 올라가고 한 번은 내려간다. SD램은 사인 곡선이 내려갈 때만 데이터를 내보내지만, DDR SD램은 올라갈 때와 내려갈 때도 데이터가 나오거나 들어가 SD램보다 데이터를 두 배로 빨리 처리한다. 하지만 이것은 이론적인 계산이고 실제로는 SD램보다 정확히 두 배로 빠르지는 않다. 그것은 읽고 쓰라는 명령 방식이 바뀌지 않아서다.
RD RAM
RD램(Rambus DRAM)은 명령과 데이터를 주고받는 방법을 바꾼 프로토콜(protocol, 규약) 방식 메모리다. 하지만 데이터를 주고받는 방법이 바뀌었을 뿐 작동 원리는 그대로 D램이다. 데이터를 묶어서 PC 시스템과 주고받게 고친 것이다. 이처럼 묶은 데이터를 시스템 버스가 제대로 알아채려면 D램과 서로 약속(protocol)을 해둬야 한다. 때문에 메모리 칩에 프로토콜을 알아채는 인터페이스를 단다. SD램은 8비트를 한 번에 주고받는 버스(bus. 데이터 통로)를 지닌 메모리 칩 8개를 엮어 병렬로 연결해서 64비트 데이터를 한 번에 주고받는다. RD램은 16비트짜리 메모리 칩을 램버스 채널(데이터 통로)에 얹어 직렬로 연결해서 16비트 그대로다. SD램은 주기 한 번에 64비트씩 데이터를 주고받지만 RD램은 16비트를 주고받는다. 한 번에 주고받는 데이터는 SD램보다 적지만 데이터 통로의 작동 속도가 400MHz이고 DDR 기술을 써서 800MHz로 끌어올렸다. 이것은 펜티엄 4 CPU와 짝을 맺게 된 이유이기도 하다. 펜티엄 4는 시스템 버스가 400MHz라서 CPU와 메인보드 칩셋이 주고받는 데이터 폭은 1초에 3.2GB다. RD램을 쓰면 메인보드 칩셋과 나누는 데이터 폭을 3.2GB로 맞출 수 있다.
적외선 센서는 발광부와 수광부로 나누어진다. 발광부에서 나온 적외선이 물체에 반사되어 수광부에 얼마나 많은 양이 들어오느냐에 따라서 수광부에 들어오는 전압의 양이 변화하게 된다. (예를 들어 발광부에서 흰색과 검정색에 적외선을 보냈을 경우 수광부에서는 반사량이 큰 흰색의 경우에 수광부에 전압이 높아지게 된다.) 그래서 우리는 그 값을 가지고 작업을 수행하게 된다.
2. 적외선 센서의 사용법
적외선 센서를 이용하는 방법은 크게 두 가지로 나뉠 수 있다.
1) 비교기를 사용하여 수광부에 들어오는 빛에 따른 출력 전압이 기준전압보다 높은 것은 HIGH로 낮은 것은 LOW로 사용하는 방법. 이 방법은 흰색과 검은색 검출에 유용하기 때문에 라인트레이서 제작에 많이 이용된다.
2) 수광부에 들어오는 빛에 따른 출력 전압을 마이크로컨트롤러의 ADC를 통해서 아날로그 값을 디지털 값으로 변환 시키는 방법. 앞의 비교기와는 틀리게 적외선이 반사되는 양이 세분화 되기 때문에 그 값을 가지고 마우스의 거리탐지로 많이 이용된다.
3. 주로 사용하는 적외선 센서
여기서는 일반적으로 라인트레이서에 많이 사용하는 소자로 하겠습니다.
1) EL-8L : 적외선 센서의 발광부로 소자의 다리가 긴쪽은 에노드로 +측에 연결되고 다리가 짧은 쪽은 캐소드로 -에 연결한다.
2) ST-8L : 적외선 센서의 수광부로서 NPN형의 트렌지스터와 비슷한 구조를 가지며, 베이스(B)단자가 없고 수광된 빛이 베이스의 구동원이 된다. 받아들인 빛의 양에 따라서 받아 들인 빛의 양에 따라서 소자의 통과 전류를 변환시킨다. 이 때문에 컬렉터(Collector)와 이미터(Emitter) 사이에 흐르는 전류의 양이 변하게 되는데, 이러한 전류의 양의 변화를 저항을 연결하여 전압으로 변환하고 이 전압을 이용해 빛이 들어왔는지 들어오지 않았는지를 판단하게 된다. 이 소자는 리드선이 짧은 부분이 컬렉터(Collector) (+) 이고, 긴쪽이 이미터(Emitter)(–) 이다.
미국비자신청서(DS-156)_작성견본.pdf
