Оглавление

I. Основы

II. Версии

III. Структура файла

IV. Заголовки

1. Версия

2. Информация об отрывке

3. Текст

4. Другая информация об отрывке.

V. Тело файла
	 _________________________________
	|
	| Меры
	|_________________________________
	|
	| Дорожки
	|_________________________________
	|		|		|
	|		|		| Нота 1
	| 		| Удар 1 	|_
	|		|		|
	|		|		| Нота i ...
	| Пары мер -    |_______________|_
	|     дорожек   |               |
	|		|		| Нота 1
	|		| Удар i ...	|_
	|		|		|
	|		|		| Нота i ...
	|_______________|_______________|_

К оглавлению
1. Меры
Меры написаны одна за другой, их число было указано ранее.

Первый байт - заголовка этой меры. В нем перечислены все данные, указанные в текущей мере.
    __
 7 |__| <- Наличие двойного бар;
 6 |__| <- Тональность меры;
 5 |__| <- Наличие маркера;
 4 |__| <- Количество альтернативных окончаний;
 3 |__| <- Конец повторения;
 2 |__| <- Начало повторения;
 1 |__| <- Знаменатель в (ключе) подписи;
 0 |__| <- Числитель (ключа) подписи.

Каждый из этих элементов присутствует, только если соответствующий бит 1.

Различных элементов письменной форме (если они есть) от низшего к высшему немного.

Exceptions are made for the double bar and the beginning of repeat whose sole presence
is enough, complementary data is not necessary.

Numerator of the (key) signature: 	Byte
 	Numerator of the (key) signature of the piece

Denominator of the (key) signature:	Byte
 	Denominator of the (key) signature of the piece

End of repeat:			Byte
	Number of repeats until the previous Beginning of repeat.
 	Nombre de renvoi jusqu'au début de renvoi précédent.

Number of alternate ending:	Byte
	The number of alternate ending.

Marker:
	The markers are written in two steps. First is written an integer equal to
	the marker's name length + 1, and then a string containing the marker's
	name. Finally the marker's color is written.

Tonality of the measure:	Byte
	This value encodes a key (signature) change on the current piece.
	It is encoded as:
		-  0: C
		-  1: G (#)
		-  2: D (##)
		- -1: F (b) ...

Summary
]]>
			http://UbuntuLinux.ru/developers/protokoly/guitar-pro-4-06-file-format-description-in-russian/feed/
		0
		
		
		
		http://UbuntuLinux.ru/developers/protokoly/guitar-pro-4-06-file-format-description/
		http://UbuntuLinux.ru/developers/protokoly/guitar-pro-4-06-file-format-description/#comments
		Sun, 21 Mar 2010 05:24:33 +0000
		
				
		
		

		http://manlinux.org/?p=78
		Читать далее →]]>
				





GUITAR PRO FILE FORMAT v4.06

Version:   1.0RC1 English
Author:    Laurent Vromman
Translator: Avery Ceo, Matthieu Wipliez
Conversion to HTML: Mauricio Gracia Gutiérrez (corrections, added information)
Property Of: Arobas-Music

Summary
	I.   GENERAL
	II.  VERSIONS
	III. FILE STRUCTURE
	IV.  HEADERS
		 1. Version
		 2. Information about the piece
		 3. Lyrics
		 4. Other information about the piece
	V.   FILE BODY
		 1. Measures
		 2. Tracks
		 3. Measure-Track pairs
		 4. Beats
		 5. Chord diagrams
 		 6. Effects on the beats
 		 7. Mix table change event
 		 8. Notes
 		 9. Effects on the notes
 		 	a. Effects on the notes
 			b. Grace notes
 		10. Bends
 	VI.  CHORDS DIAGRAMS




I. GENERAL
Values of type "integer" are stored in 4 bytes.

Values of type "short int" are stored in 2 bytes.

Values of type "byte" are stored in 1 byte.
Values of type "integer" and "byte" presented in this document

are written from left to right of the the LSB (least significant byte)

to the MSB (most significant byte).
The colors are stored in 4 bytes in the following way, the data is written from left to right of

the LSB (least significant byte) to the MSB (most significant byte):
   __
3 |__| <- White byte, it always evaluates to 0x00;
2 |__| <- Blue;
1 |__| <- Green;
0 |__| <- Red.
When this document uses the expression "character string," it means a couple of

a first byte encoding the number 'n' of characters in the string (consequently limited to 255 characters),

followed by the 'n' characters themselves.
The musical notes are stored as integers. The value of the C(0) is 0, and each incrementation of

the variable represents a half tone:
- C#(0) = 1;
- C (1) = 12;
- E (2) = 28 ...
Summary

II. VERSIONS
The Guitar Pro format has evolved with the program to integrate the new functionalities that it provides.
This document describes the structure of the Guitar Pro version 4.06 files only.
Summary

III. File Structure
	 _______________________________________________________
	|	|						|
	|	| Version					|
	|	|_______________________________________________|
	|	|						|
	|	| Tablature					|
	|	|_______________________________________________|
	|Headers|						|
	|	| Lyrics					|
	|	|_______________________________________________|
	|	|						|
	|	| Other Tablature Information			|
	|_______|_______________________________________________|
File	|	|						|
	|	| Measures					|
	|	|_______________________________________________|
	|	|						|
	|	| Tracks					|
	|	|_______________________________________________|
	|	|		|		|		|
	|	|		|		| Note 1 	|
	|Body	| 		| Beat 1 	|_______________|
	|	|		|		|		|
	|       |		|		| Note i ...	|
	|       | Measure-Track |_______________|_______________|
	|       | Pairs  	|               |        	|
	|	|		|		| Note 1	|
	|       |               | Beat i ...	|_______________|
	|	|		|		|		|
	|	|		|		| Note i ...	|
	|_______|_______________|_______________|_______________|
	|							|
	| Chord Diagrams					|
	|_______________________________________________________|

Summary




IV. HEADERS
The difficulty in reading about the Guitar Pro files resides in the variable
size of the file's header.  Reading the file must therefore be done sequentially.
	Structure
   	 _
	|
	| Version
	|_
	|
	| Tablature Information
	|_
	|
	| Lyrics
	|_
	|
	| Other Tablature Information
	|_

Summary

1. Version
0x00000000:  30 character string (not counting the byte announcing the real length of
the string as explained in I. GENERAL) representing the version number.  Only the first n
characters (n being given by the value described previously) characters are considered.
The different values possible at this time are:
	FICHIER GUITARE PRO v1
	FICHIER GUITARE PRO v1.01
	FICHIER GUITARE PRO v1.02
	FICHIER GUITARE PRO v1.03
    	FICHIER GUITARE PRO v1.04
    	FICHIER GUITAR PRO v2.20
    	FICHIER GUITAR PRO v2.21
    	FICHIER GUITAR PRO v3.00
    	FICHIER GUITAR PRO v4.00
    	FICHIER GUITAR PRO v4.06
    	FICHIER GUITAR PRO L4.06
*Translator's Note: "Fichier" is French for "File".  It is left untranslated above, as
the program expects the string in French.
Only the specifications relating to version "FICHIER GUITAR PRO v4.06" are described here.
After this point (0x0000001F), the data is written sequentially without a precise address.
Summary

2. Information About the Piece
The follollowing information is presented in the form of a block of data containing:
	- an integer representing the size of the stored information + 1;
	- the string of characters representing the data
This structure requires that a null string be written 01 00 00 00 00 in the file.
The information concerned is, in order of reading within the file:
	- The title of the piece;
	- The subtitle of the piece;
	- The interpret of the piece;
	- The album from which the piece was taken;
	- The author of the piece;
	- The copyright;
	- The name of the author of the tablature;
	- An 'instructional' line about the tablature.
The following section contains information regarding the 'notice' (note) field in the piece's properties.
It begins with an integer containing the number of lines of Nb_Notice notes, then Nb_Notice instances of
the structure previously described, each containing lines of notes.
The file then contains a byte determining the 'TripletFeel' attribute of the piece.
If TripletFeel is activated, the value is 1.  If not, the integer value is 0.
Summary

3. Lyrics
The next section of the file contains the lyrics associated with the piece.
WARNING: The strings presented in this section and in this section only do not conform to the
format presented in "I. General", but are written directly.
The lyrics section begins with an integer giving the number of the track with which the
lyrics are associated.
Then, for each of the 5 lines of lyrics generated by Guitar Pro 4, the file contains an
integer representing the number of characters in the string followed by the character string itself.
Summary

4. Other information about the piece
The next data is:

The tempo:			Integer

The key:			Byte
	This value encodes the key (signature) at the beginning of the piece.  It is encoded as:
		-  0: C
		-  1: G (#)
		-  2: D (##)
		- -1: F (b) ...

The Octave:			Byte
	The standard value is 0. It becomes 8 if the sheet is to be played one octave higher (8va).

        This functionality is not yet used, but is presented as a preview of a revision of the GP4 format.

Midi Channels:
	Table of midi channels.  There are 4 ports and 16 channels, the channels are stored in this order:
		port1/channel1  - port1/channel2 ... port1/channel16 - port2/channel1 ...

		Each element of the table has the following form:
			Instrument: 	Integer
  			Volume: 	Byte
  			Balance: 	Byte
  			Chorus: 	Byte
  			Reverb: 	Byte
  			Phaser: 	Byte
  			Tremolo: 	Byte

  			blank1: 	byte => Backward compatibility with version 3.0
  			blank2:		byte => Backward compatibility with version 3.0

Number of Measures:   Integer
Number of Tracks:    Integer
Summary




V. FILE BODY
	 _________________________________
	|
	| Mesures
	|_________________________________
	|
	| Tracks
	|_________________________________
	|		|		|
	|		|		| Note 1
	| 		| Beat 1 	|_
	|		|		|
	|		|		| Note i ...
	| Measure-track |_______________|_
	|     Pairs     |               |
	|		|		| Note 1
	|		| Beat i ...	|_
	|		|		|
	|		|		| Note i ...
	|_______________|_______________|_



Summary

1. Measures
The measures are written one after another, their number having been specified previously.

The first byte is the measure's header.  It lists the data given in the current measure.
    __
 7 |__| <- Presence of a double bar;
 6 |__| <- Tonality of the measure;
 5 |__| <- Presence of a marker;
 4 |__| <- Number of alternate ending;
 3 |__| <- End of repeat;
 2 |__| <- Beginning of repeat;
 1 |__| <- Denominator of the (key) signature;
 0 |__| <- Numerator of the (key) signature.

Each of these elements is present only if the corresponding bit is a 1.

The different elements are written (if they are present) from lowest to highest bit.

Exceptions are made for the double bar and the beginning of repeat whose sole presence
is enough, complementary data is not necessary.

Numerator of the (key) signature: 	Byte
 	Numerator of the (key) signature of the piece

Denominator of the (key) signature:	Byte
 	Denominator of the (key) signature of the piece

End of repeat:			Byte
	Number of repeats until the previous Beginning of repeat.
 	Nombre de renvoi jusqu'au début de renvoi précédent.

Number of alternate ending:	Byte
	The number of alternate ending.

Marker:
	The markers are written in two steps. First is written an integer equal to
	the marker's name length + 1, and then a string containing the marker's
	name. Finally the marker's color is written.

Tonality of the measure:	Byte
	This value encodes a key (signature) change on the current piece.
	It is encoded as:
		-  0: C
		-  1: G (#)
		-  2: D (##)
		- -1: F (b) ...

Summary

2. Tracks
The tracks are written one after another, their number having been specified previously.

The first byte is the track's header.  It precises the track's attributes:
    __
 7 |__| <- Blank bit;
 6 |__| <- Blank bit;
 5 |__| <- Blank bit;
 4 |__| <- Blank bit;
 3 |__| <- Blank bit;
 2 |__| <- Banjo track;
 1 |__| <- 12 stringed guitar track;
 0 |__| <- Drums track.

Name:				String
	A 40 characters long string containing the track's name.

Number of strings:		Integer
	An integer equal to the number of strings of the track.

Tuning of the strings:		Table of integers
	The tuning of the strings is stored as a 7-integers table, the "Number of
	strings" first integers being really used. The strings are stored from
	the highest to the lowest.

Port:				Integer
	The number of the MIDI port used.

Channel:			Integer
	The number of the MIDI channel used. The channel 10 is the drums channel.

ChannelE:			Integer
	The number of the MIDI channel used for effects.

Number of frets:		Integer
	The number of frets of the instrument.

Height of the capo:		Integer
	The number of the fret on which a capo is present. If no capo is used, the
	value is 0x00000000.

Track's color:			Color
	The track's displayed color in Guitar Pro.

Summary

3. Measures-Tracks pairs
The list of beats per track and per measure is then written to the file in the
following order:

	Measure 1/Track 1
	Measure 1/Track 2
	...
	Measure 1/Track M
	Measure 2/Track 1
	...
	Measure 2/Track M
	...
	Measure N/Track 1
	Measure N/Track 2
	...
	Measure N/Track M

A measure-track pair is written in two steps. We first write the number of beats
in the current pair:

Number of beats:		Integer
	Integer indicating the number of beats the measure-track pair contains.

After what we directly write the beat details (which are described in the next section).

Summary

4. A beat
The first byte is the beat header. It lists the data present in the current beat:
    __
 7 |__| <- Blank bit;
 6 |__| <- Status: True if the beat is empty of if it is a rest;
 5 |__| <- The beat is a n-tuplet;
 4 |__| <- Presence of a mix table change event;
 3 |__| <- Presence of effects;
 2 |__| <- Presence of a text;
 1 |__| <- Presence of a chord diagram;
 0 |__| <- Dotted notes.


Status:				Byte
	If the bit 6 is true, we start by writing the beat status. The value is
	0x00 if the beat is empty and 0x02 if it is a rest.

Beat duration:			Byte
	The basic beat duration is a eighth note, which is equivalent to a
	time duration of 1. We thus obtain the following relations:
 		* -2:	Whole note;
 		* -1:	Half note;
 		*  0:	Quarter note;
 		*  1:	Eighth note;
 		*  2:	Sixteenth note;
 	 	*  3:	Thirty-second note;
 	 	* ...

N-tuplet:			Integer
	If the bit 5 of the header byte is true, this integer corresponds to the
	'n' in 'n-tuplet': 3, 5, 6, 7, 9, 10, 11, 12 and 13.

Chord diagram:
	If the presence of a chord diagram is indicated by the bit 1 of the
	header, it is then written here. The detail of this operation is specified
	in paragraph V.5 Chords diagrams.

Text:
	If the presence of a text is indicated by the bit 2 of the header, it is
	written here. It behaves like most of the previous strings. We
	first find an integer coding the text length + 1, followed by the string
	containing the text (at the format described in I. GENERAL).

Effect on beats:
	If the presence of an effect is indicated by the bit 3 of the header, it
	is written at this place. The detail of this operation is specified in the
	paragraph V.6 Effects on beats. Effects on beats include tremolo bars,
	bends...

Mix table change event:
	If the presence of an event linked to the mix table is indicated by the
	bit 4 of the header, it is written here. The detail of this operaion is
	specified in the paragraph V.7 Mix table change event.

Note:
	The note itself is written here. The detail of this operation is specified
	in the paragraph V.8 Note.

Summary

5. Chords diagrams
Header:				Byte
	This value is 0x01, indicating a Guitar Pro 4 format chord.

Sharp: 				Byte
	Determines if the chord is displayed sharp or flat.

Blank1,
Blank2,
Blank3: 			Bytes
	Blank bytes needed for ascendant compatibility with versions 3 of the software.

Root:				Byte
 	* -1 for the customized chords
 	*  0: C
 	*  1: C#...

Major/minor:			Byte
	Determines the chord type as followed:
		-  0: M
		-  1: 7
		-  2: 7M
		-  3: 6
		-  4: m
		-  5: m7
		-  6: m7M
		-  7: m6
		-  8: sus2
		-  9: sus4
		- 10: 7sus2
		- 11: 7sus4
		- 12: dim
		- 13: aug
		- 14: 5

Nine, Eleven of Thirteen:	Byte
	Determines if the chord goes until the ninth, the eleventh, or the thirteenth.

Bass: 				Integer
	Lowest note of the chord. It gives the chord inversions.

Diminished/Augmented		Integer
	Tonality linked with 9/11/13:
		0: perfect ("juste")
		1: augmented
		2: diminished

add: 				Byte
	Allows to determine if a 'add' (added note) is present in the chord.

Name: 				String
	20 characters long string containing the chord name.


Blank4,
Blank5: 			Bytes
	Blank bytes needed for ascendant compatibility with versions 3 of the software.

Fifth: 				Byte
	Tonality of the fifth:
		0: perfect ("juste")
		1: augmented
		2: diminished

Ninth: 				Byte
	Tonality of the ninth:
		0: perfect ("juste")
		1: augmented
		2: diminished
	This tonality is valid only if the value "Nine, Eleven or Thirteen" is 11 or 13.

Eleventh: 			Byte
	Tonality of the eleventh:
		0: perfect ("juste")
		1: augmented
		2: diminished
	This tonality is valid only if the value "Nine, Eleven or Thirteen" is 13.

Base fret:			Integer
	Shows the fret from which the chord is displayed.

Frets: 				List of 7 integers.
	Corresponds to the fret number played on each string, from the highest to the lowest.
	-1 means a string unplayed.
	0 means a string played "blank" (ie no fret).

Number of barres: 		Byte
	Indicates the number of barres there are in the chord. A chord can contain up to 5 barres.

Fret of the barre:		List of 5 Bytes
	Indicates the fret number of each possible barre.

Barre start:			List of 5 Bytes
	Indicates the first string of the barre, 1 being the highest.
        The list order matches the chord different barres frets list order.

Barre end: 			List of 5 Bytes
	Indicates the first string of the barre, 1 being the lowest.
        The list order matches the chord different barres frets list order.

Omission1,
Omission3,
Omission5,
Omission7,
Omission9,
Omission11,
Omission13:  			Bytes
	Gives the notes there are in the chord.
        If the value is 0x00, the note is not in the chord, and if the value is
        0x01, the note is in the chord. 9, 11 or 13 can only be present
        for a "Nine, Eleven or Thirteen" big enough.

Blank6: 			Byte
	Blank byte needed for ascendant compatibility with versions 3 of the software.

Fingering:			List of 7 Bytes
	Describes the fingering used to play the chord.
        Below is given the fingering from the highest string to the lowest:
		-2: unknown;
		-1: X or 0 (no finger);
		 0: thumb;
		 1: index;
		 2: middle finger;
		 3: annular;
		 4: little finger.

ShowDiagFingering:		Byte
	If it is 0x01, the chord fingering is displayed.
	If it is 0x00, the chord fingering is masked.

Summary

6. Effects on beats
The first byte is the header of effects linked to beats. It gives information about existing effects:
    __
 7 |__| <- Blank bit;
 6 |__| <- Stroke effect;
 5 |__| <- Tapping, popping or slapping effect;
 4 |__| <- unused bit -> remainings of version 3;
 3 |__| <- unused bit -> remainings of version 3;
 2 |__| <- unused bit -> remainings of version 3;
 1 |__| <- unused bit -> remainings of version 3;
 0 |__| <- unused bit -> remainings of version 3.

The 2nd byte is linked with effects new to the version 4 of the software.
    __
 7 |__| <- Blank bit;
 6 |__| <- Blank bit;
 5 |__| <- Blank bit;
 4 |__| <- Blank bit;
 3 |__| <- Blank bit;
 2 |__| <- Tremolo Bar;
 1 |__| <- Pickstroke;
 0 |__| <- Rasguedo.

The effects, if any, are then written in the following order:

Tapping/Popping/Slapping:	Byte
	The presence of this effect is set by the bit 5 of the first header byte.
        It is written as:
 		0: None
 		1: Tapping
 		2: Slapping
 		3: Popping (bass guitar)

Tremolo Bar:			Bend
	The presence of this effect is set by the bit 2 of the second header byte.
 	The tremolo bar is saved as a BEND, as described in the paragraph V.10 Bends.

UpStroke:			Byte
	The presence of this effect is set by the bit 6 of the first header byte.
        It can take different values depending on the stroke speed:
 		0: none;
 		1: hundred twenty eighth note;
 		2: sixty-fourth note;
 		3: thirty-second note;
 		4: sixteenth note;
 		5: eighth note;
 		6: quarter note.

DownStroke:			Byte
	The presence of this effect is set by the bit 6 of the first header byte.
        It can take different values depending on the stroke speed:
 		0: none;
 		1: hundred twenty eighth note;
 		2: sixty-fourth note;
 		3: thirty-second note;
 		4: sixteenth note;
 		5: eighth note;
 		6: quarter note.

Rasguedo:
	The rasguedo is set if the bit 0 of the second header byte is set. It is
        a complement to the strokes, so it does not need any additional data.


Pickstroke:			Byte
	The presence of this effect is set by the bit 1 of the second header byte.
        It can take different values:
 		0: none;
 		1: going up;
 		2: going down.


Summary

7. Mix table change event
Instrument:   			Byte
	Gives the number of the new instrument. The value is -1 if no instrument change occurs.

Volume:       			Byte
	Gives the new volume value. The value is -1 if no volume change occurs.

Pan:       			Byte
	Gives the new pan value. The value is -1 if no pan change occurs.

Chorus:       			Byte
	Gives the new chorus value. The value is -1 if no chorus change occurs.

Reverb:       			Byte
	Gives the new reverb value. The value is -1 if no reverb change occurs.

Phaser:       			Byte
	Gives the new phaser value. The value is -1 if no phaser change occurs.

Tremolo:      			Byte
	Gives the new tremolo value. The value is -1 if no tremolo change occurs.

Tempo:        			Integer
	Gives the new tempo value. The value is -1 if no tempo change occurs.

Volume change duration:		Byte
	Gives the volume change duration in beats.

Pan change duration: 		Byte
	Gives the pan change duration in beats.

Chorus change duration:		Byte
	Gives the chorus change duration in beats.

Reverb change duration:		Byte
	Gives the reverb change duration in beats.

Phaser change duration:		Byte
	Gives the phaser change duration in beats.

Tremolo change duration:	Byte
	Gives the tremolo change duration in beats.

Tempo change duration:		Byte
	Gives the tempo change duration in beats.

The next byte precises if the changes apply only to the current track (if the
matching bit is 0), or to every track (if it is 1).
    __
 7 |__| <- Blank bit;
 6 |__| <- Blank bit;
 5 |__| <- Tremolo;
 4 |__| <- Phaser;
 3 |__| <- Reverb;
 2 |__| <- Chorus;
 1 |__| <- Pan;
 0 |__| <- Volume.

Summary

8. Note
The first byte is the note header. It lists the information about the different
parameters linked to the note:
    __
 7 |__| <- Right hand or left hand fingering;
 6 |__| <- Accentuated note;
 5 |__| <- Note type (rest, empty note, normal note);
 4 |__| <- Note dynamic;
 3 |__| <- Presence of effects linked to the note;
 2 |__| <- Ghost note;
 1 |__| <- Dotted note;
 0 |__| <- Time-independent duration.

Note type:			Short Int
 	If the bit 5 is true, we start by writing the note type. The value is:
 		0x0100 if the note is normal;
 		0x0200 if the note is a ghost note;
 		0x0300 if the note is a tie note.

Note duration:
	If the bit 0 is true, we write the 2 following information linked to the
        note duration.

	Time duration:		Byte
        	The basic time duration is the quarter note, which is equivalent
                to a time duration of 1. Therefore, we obtain the relations:
 			* -2:	Whole Note;
 			* -1:	Half note;
 			*  0:	Quarter note;
 			*  1:	Eighth note;
 			*  2:	Sixteenth note;
 	 		*  3:	Thirty-second note;
 	 		* ...

 	N-tuplet:		Byte
        	This int matches the N in "N-tuplet" (ie 3, 5, 6, 7, 9, 10, 11, 12, 13).

Note dynamic:			Byte
	If the bit 4 of the header byte is true, we write here the note strength
        with the following rule:
		- 1: ppp
		- 2: pp
		- 3: p
		- 4: mp
		- 5: mf
		- 7: f
		- 8: ff
		- 9: fff
	If the bit 4 is false, we then consider that the note is forte (value 6).

Fret number:			Byte
	If the bit 5 is true, we write here the number of the fret on which the note
        is applied.

Fingering:			List of 2 bytes
	If the bit 7 is true, we write here successively the fingerings left hand,
        then right hand, each of them being written on one byte. The fingering
        is coded this way:
		-1: nothing;
		 0: thumb;
		 1: index;
		 2: middle finger;
		 3: annular;
		 4: little finger.

Effects on the note:
	If the presence of an effect is indicated by the bit 3 of the header, it
        is saved at this place. The details of this operation is specified in the
        next paragraph. Those include for example vibratos, palm muting,
        slides, harmonices...

Summary

9. Effects on the notes
a. Effects on the notes
The effects presence for the current note is set by the 2 header bytes.

First byte:
    __
 7 |__| <- Blank bit;
 6 |__| <- Blank bit;
 5 |__| <- Blank bit;
 4 |__| <- Grace note presence;
 3 |__| <- Let ring;
 2 |__| <- Presence of a slide from the current note (version 3);
 1 |__| <- Presence of a hammer-on or a pull-off from the current note;
 0 |__| <- Presence of a bend.

Second byte:
    __
 7 |__| <- Blank bit;
 6 |__| <- Left hand vibrato;
 5 |__| <- Trill;
 4 |__| <- Harmonic note;
 3 |__| <- Presence of a slide from the current note;
 2 |__| <- Tremolo picking;
 1 |__| <- Palm Mute;
 0 |__| <- Note played staccato.

Bend:
	If the bit 0 of the first header byte is true, we write here the bend as
        described in section V.10. Bends.

Grace Note:
	If the bit 4 of the first header byte is true, we write here the data
        relative to the Grace Note, as described in section V.9.b Grace Notes.

Tremolo Picking:		Byte
	If the bit 2 of the second header byte is true, the information linked to
        tremolo picking are saved here. It is encoded like this:
		- 1: eighth note;
		- 2: sixteenth note;
		- 3: thirty-second note.

Slide:				Byte
	If the bit 3 of the second header byte is true, the information linked to
        the slide is stored here and is coded like this:
		* -2: slide into from above
		* -1: slide into from below
		*  0: no slide
		*  1: shift slide
		*  2: legato slide
		*  3: slide out of downwards
		*  4: slide out of upwards

Harmonics:			Byte
	If the bit 4 of the second header byte is true, the information linked to
        the harmonics is stored here and is coded like this:
		- 0:  None
		- 1:  Natural
		- 15: Artificial+5
		- 17: Artificial+7
		- 22: Artificial+12
		- 3:  Tapped
		- 4:  Pitch
		- 5:  Semi

Trill:
	If the bit 5 of the second header byte is true, the information linked to
        the Trill effect is stored here. It is written in two steps:
		Fret:		Byte
			The fret the trill is made with.

		Period:		Byte
                	The period between each note. The value is encoded as:
				- 0: Quarter note;
				- 1: Eighth note;
				- 2: Sixteenth note.

The following effects are present if the bit of the header is true:
	- Let ring
	- Presence of a hammer-on or a pull-off from the current note
	- Left hand vibrato
	- Palm Mute
	- Note played staccato.

Summary

b. Grace notes
The grace notes are stored in the file with 4 variables, written in the following
order.

Fret:				Byte
	The fret number the grace note is made from.

Dynamic: 			Byte
	The grace note dynamic is coded like this:
		- 1: ppp
		- 2: pp
		- 3: p
		- 4: mp
		- 5: mf
		- 6: f
		- 7: ff
		- 8: fff
	The default value is 6.

Transition:			Byte
	This variable determines the transition type used to make the grace note:
		- 0: None
		- 1: Slide
		- 2: Bend
		- 3: Hammer

Duration:			Byte
	Determines the grace note duration, coded this way:
		- 3: Sixteenth note.
		- 2: Twenty-fourth note.
		- 1: Thirty-second note.


Summary

10. Bends
Type:				Byte
	Gives the bend type. Different types are allowed and are context-dependent (tremolo bar or bend).
	The model list is:
		Common:
			- 0: None

		Bend specific:
			- 1: Bend
			- 2: Bend and Release
			- 3: Bend and Release and Bend
			- 4: Prebend
			- 5: Prebend and Release

		Tremolo bar specific:
			- 6: Dip
			- 7: Dive
			- 8: Release (up)
			- 9: Inverted dip
			-10: Return
			-11: Release (down)

Value:				Integer
	Bend height. It is 100 per tone and goes by quarter tone.
		* Normal position:	0;
		* Quarter tone: 	25;
		* Half tone:		50;
		* Three-quarters tone:	75;
		* Whole tone:		100;
		... until
		* Three tones:		300.


Number of points:		Integer
	Number of points used to display the bend. Is followed by the list of points.

List of points:
	Each point is written like this:
		Absolute time position		Integer
			Gives the point position from the previous point. This value goes between 0 and 60
                        and represents sixties of the note duration.

		Vertical position		Integer
                	It is 100 per tone and goes by quarter tone.
			* Normal position:	0;
			* Quarter tone: 	25;
			* Half tone:		50;
			* Three-quarters tone:	75;
			* Whole tone:		100;
			... until
			* Three tones:		300.

		Vibrato				Byte
                	Determines how to play the section, with different vibrato types:
				- 0: none
				- 1: fast
				- 2: average
				- 3: slow

Summary




VI. CHORDS DIAGRAMS
Number of chords:		Integer
	Number of chords to write in the chords diagram list.

Then comes the written chords list, as described in V.5 Chords diagrams.




This page is part of the DGuitar Home Page

]]>
			http://UbuntuLinux.ru/developers/protokoly/guitar-pro-4-06-file-format-description/feed/
		0
		
		
		
		http://UbuntuLinux.ru/developers/protokoly/linux-sound-api-overview/
		http://UbuntuLinux.ru/developers/protokoly/linux-sound-api-overview/#comments
		Sat, 20 Mar 2010 16:31:47 +0000
		
				
		
		
		
		
		
		
		

		http://manlinux.org/?p=70
		Читать далее →]]>
				Оригинал: A Guide Through The Linux Sound API Jungle

Автор: Lennart Poettering

Дата публикации: 24 сентября 2008 г.

Перевод: Максим Белозеров

Дата перевода: 25 августа 2009 г.

Во время миниконференции, посвященной теме аудио, на конференции Linux Plumbers выяснилась одна вещь: программистам часто трудно решить, какие из звуковых API для каких целей использовать при создании аудиопрограмм для Linux. Давайте попробуем разобраться в этих джунглях:


Что вы хотите сделать?

Я хочу написать еще один медиаплеер!
Используйте GStreamer! (Но если вы собираетесь писать только для KDE, тогда используйте альтернативный вариант — Phonon).
Я хочу добавить в свое приложение звуковые оповещения для событий!
Используйте libcanberra, устанавливайте звуковые файлы в соответствии со спецификациями XDG по звуковым темам и их именованию (но если вы собираетесь писать только для KDE, тогда как альтернативу можно использовать KNotify, хотя у него немного другие задачи).
Я хочу создавать профессиональные аудиоредакторы, программы для звукозаписи, работы с MIDI и синтезаторы!
Используйте JACK и (или) полный интерфейс ALSA.
Мне нужно простое воспроизведение и захват PCM-аудио! 1)
Используйте безопасную часть ALSA.
Хочу добавить звук к своей игре!
Используйте звуковой API из SDL для полноэкранных игр, а libcanberra для простых игр со стандартным пользовательским интерфейсом типа Gtk+.
Хочу написать микшер!
Используйте уровень, с которым собираетесь непосредственно работать: если хотите обеспечить поддержку усовершенствованных программных микшеров, используйте API управления громкостью PulseAudio. Чтобы обеспечить поддержку аппаратных микшеров, используйте API микшера ALSA.
Я хочу писать аудиоприложения промежуточного уровня!
Используйте полный стек ALSA.
Мне нужно написать аудиоприложения для встроенных систем!
Для технического применения обычно подходит безопасная часть ALSA, но все зависит от конкретного случая.
Хотите узнать больше о различных звуковых API?
GStreamer
GStreamer — стандарт де-факто для систем управления медиапотоками для рабочих станций Linux. Он поддерживает кодирование и декодирование аудио- и видеопотоков. Его можно применять для самых разных целей от простого воспроизведения аудиофайлов до сложных систем вещания по сети. GStreamer поддерживает широкий диапазон кодеков и звуковых подсистем. GStreamer не очень подходит для воспроизведения простого PCM и для приложений, работающих с малой задержкой или в реальном масштабе времени. GStreamer переносим и может использоваться не только в Linux. Среди поддерживаемых звуковых подсистем — ALSA, OSS и PulseAudio. [Справочник и руководство по программированию]
libcanberra
libcanberra — звуковой API для абстрактных событий. В нем реализованы спецификации XDG по звуковым темам и их именованию. libcanberra разработана для GNOME, но сама по себе не зависит от GNOME, Gtk или GLib и может использоваться в других окружениях рабочего стола. Помимо простого интерфейса для воспроизведения аудиофайлов libcanberra обеспечивает кэширование (что весьма полезно для сетевых тонких клиентов) и позволят передавать различные метаданные звуковым подсистемам, что можно использовать для создания дополнительных удобств для пользователя (например, для озвучивания событий позиционирования) и для улучшения восприятия. libcanberra поддерживает различные звуковые подсистемы и может портироваться на системы, отличные от Linux. Среди поддерживаемых звуковых подсистем — ALSA, OSS, PulseAudio и GStreamer. [Справочник по API]
JACK
JACK — звуковая систем для коммутации профессиональных аудиоприложений и аппаратных выходов. Основной акцент делается на низких задержках сигнала и коммутации между приложениями. Эта система не нужна для обычного рабочего стола или для встраиваемых систем. От этого API не будет пользы, если вам требуется простое воспроизведение PCM. JACK поддерживает различные звуковые подсистемы, но лучше работает с ALSA. JACK можно переносить на другие ОС. Среди поддерживаемых звуковых подсистем — ALSA и OSS. [Справочник по API]
Полный интерфейс ALSA
ALSA — это API для воспроизведения и записи PCM-аудио в Linux. ALSA в основном работает с оборудованием, хотя поддерживаются и другие звуковые подсистемы (с некоторыми ограничениями, см. ниже). Название ALSA применяется как к драйверам ядра Linux, так и к библиотеке пространства пользователя, использующей их. Библиотека ALSA полнофункциональная и переносимая (с некоторыми ограничениями). Полный API ALSA может показаться очень сложным и большим. Зато он поддерживает практически все функции современного звукового оборудования. Часть функциональности программного интерфейса ALSA ограничивается поддержкой оборудования ядром Linux (в отличие от программных звуковых серверов и драйверов пользовательского пространства, таких как аудио для Bluetooth и FireWire) и драйверами для Linux. [Справочник по API]
Безопасная часть ALSA
Только часть полного API ALSA работает со всеми звуковыми подсистемами, поддерживаемыми ALSA. Рекомендуется придерживаться этойбезопасной части, если вы пишете программы для ALSA, которые должны быть переносимыми, не устаревающими и совместимыми со звуковыми серверами, Bluetooth-аудио и FireWire-аудио. Ниже подробно описывается, какие из функций ALSA считаются безопасными.Безопасная часть API ALSA — подходящая абстракция для переносимого базового воспроизведения и записи PCM, которая используется не только для устройств, поддерживаемых драйвером ядра ALSA. Среди поддерживаемых звуковых подсистем — устройства драйвера ядра ALSA, OSS, PulseAudio и JACK.
Phonon и KNotify
Phonon — высокоуровневая абстракция для систем потокового воспроизведения, таких как GStreamer, но этим ее функциональность не ограничивается. Поддерживается несколько звуковых подсистем. KNotify — система для “оповещений” в широком смысле, не только звуковых. Однако в ней пока не поддерживаются спецификации XDG по звуковым темам и их именованию, а также не поддерживается кэширование или передача метаданных оповещения звуковой подсистеме нижнего уровня. KNotify поддерживает разные подсистемы для воспроизведения звука через Phonon. Оба API специфичны для KDE/Qt и для приложений за пределами KDE/Qt их лучше не использовать. [Справочник по API Phonon] [Справочник по API KNotify]
SDL
SDL — переносимый API, используемый в основном для разработки полноэкранных игр. Среди прочего он включает в себя и переносимый аудиоинтерфейс. Среди звуковых подсистем, поддерживаемых SDL — OSS, PulseAudio и ALSA. [Справочник по API]
PulseAudio
PulseAudio — звуковая система для Linux-десктопов и встроенных окружений, работающая в пространстве пользователя, обычно поверх ALSA. PulseAudio поддерживает сквозной тракт передачи, раздельный уровень громкости для разных приложений, озвучивание пространственных оповещений, позволяет на лету переключать звуковые потоки между устройствами и выполнять многие другие высокоуровневые операции. PulseAudio добавляет к аудиостеку Linux модель бесперебойного воспроизведения (см. glitch-free). PulseAudio не подходит для профессиональных систем работы с аудио. PulseAudio можно портировать на системы, отличные от Linux. В PulseAudio есть собственный API, а также поддержка безопасной части ALSA, а также ограниченная, основанная на LD_PRELOAD совместимость с OSS. Среди поддерживаемых PulseAudio звуковых подсистем — OSS и ALSA. Также есть возможность взаимодействия с JACK. [Справочник по API]
OSS
Open Sound System — низкоуровневый PCM API, поддерживаемый многими Unix-системами, в том числе и Linux. Сначала это была стандартная аудиосистема Linux, современные ядра Linux поддерживают третью версию API, OSS3. OSS3 считается устаревшим и был полностью заменен на ALSA. Уже появился OSS4, преемник OSS3, но практически не играет роли для Linux и не поддерживается в стандартных ядрах и распространенных дистрибутивах. OSS API работает на низком уровне, на основе прямых обращений к интерфейсам ядра с помощью ioctl(). Поэтому его неудобно использовать и практически нельзя виртуализировать для использования в аудиосистемах вне ядра, таких как звуковые серверы (например PulseAudio) или драйверы пространства пользователя (например Bluetooth- или FireWire-аудио). Модель с учетом задержек в OSS3 вообще нельзя верно преобразовать для программных звуковых серверов, а также возникают проблемы с оборудованием, подключенным не по шине PCI, например по USB. Кроме того, OSS не конвертирует, не перераспределяет или перекодирует типы дискретизации при необходимости. Это значит, что клиентские приложения, которые должны поддерживать OSS, обязаны содержать полный набор утилит для конвертации, переназначения и перекодирования на тот случай, если оборудование не поддерживает аппаратно требуемые параметры дискретизации. Среди современных звуковых карт часто встречается поддержка только S32LE на 48 кГц. Если предполагается, что клиентское приложение для OSS всегда воспроизводит звук в с дискретизацией S16LE на 44,1 кГц, ничего не выйдет. OSS3 можно портировать на другие Unix-совместимые ОС, но с учетом некоторых различий. В OSS также нет нормальной поддержки многоканального звука и другой функциональности современных аудиосистем. OSS устарел, его не следует использовать для новых приложений. В ALSA и PulseAudio есть ограниченная совместимость с OSS, основанная на LD_PRELOAD. [Руководство по программированию]
Все звуковые системы и API, перечисленные выше, поддерживаются во всех популярных современных дистрибутивах. Для поддержки libcanberra может потребоваться последний выпуск вашего дистрибутива для разработчиков.
Все звуковые системы и API, перечисленные выше, подходят для разработки коммерческих приложений с закрытым кодом, так как они лицензированы под LGPL или более либеральными лицензиями, либо в клиентскую часть не включаются библиотеки.
Когда и где стоит использовать тот или иной API?
GStreamer
GStreamer хорошо подходит для высокоуровневых задач. Например, если вам надо воспроизвести аудиофайл или видеопоток, не заботясь о несущественных деталях на уровне кодеков или PCM.
libcanberra
libcanberra лучше всего подходит для озвучивания ввода в пользовательских интерфейсах или для воспроизведения простых звуковых файлов для оповещений.
JACK
JACK хорошо подходит для профессиональных программ аудиозаписи или в случаях, когда требуется перекрестная коммутация между приложениями.
Полный интерфейс ALSA
Полный интерфейс ALSA лучше использовать для программ “промежуточного уровня”, или если вы собираетесь использовать очень специфичные возможности оборудования, которые могут понадобиться для задач аудиозаписи.
Безопасная часть ALSA
Безопасный интерфейс ALSA хорошо подходит для программ, которые занимаются записью/воспроизведением простых PCM-данных с аппаратных устройств или программных звуковых подсистем.
Phonon и KNotify
Phonon и KNotify стоит использовать только в приложениях KDE/Qt для высокоуровневого воспроизведения медиаданных и для простых звуковых оповещений соответственно.
SDL
SDL подходит для полноэкранных игр.
PulseAudio
На данный момент API PulseAudio следует использовать только для приложений, которые должны обеспечивать функциональность, специфичную для звукового сервера (например, микшеров) или если уровень абстракций вывода PCM уже реализован в приложении и имеет смысл добавить поддержку PulseAudio для минимизации количества уровней в аудиостеке.
OSS
OSS не следует использовать для новых программ.
Хотите узнать больше о безопасной части ALSA?
Вот список того, что следует и не следует делать, если вы хотите, чтобы ваши программы не устаревали и нормально работали с неаппаратными звуковыми подсистемами и низкоуровневыдрайверами пространства пользователя, такими как Bluetooth- и FireWire-аудио. Некоторые из этих рекомендаций применимы также и для полного API ALSA, но часть функциональности можно считать устаревшей в любом случае.
У вас должна быть серьезная причина, чтобы писать код, не соответствующий этим правилам. Иначе этот код можно будет просто считатьнеработоспособным!
Что НЕ НАДО делать:

Не используйте “обработчики async”, например snd_async_add_pcm_handler() и тому подобные. Асинхронные обработчики реализованы с применением сигналов POSIX, а это весьма спорное их применение, особенно для библиотек и подключаемых модулей. Даже если нежелательно ограничиваться безопасной частью ALSA, лучше не использовать такие функции. Здесь подробно описывается, почему не стоит использовать сигналы для ввода-вывода звука.
Не берите данные из конфигурационного файла ALSA самостоятельно или с помощью любой из функций ALSA, подобныхsnd_config_xxx(). Если нужно пронумеровать аудиоустройства, используйте snd_device_name_hint() (и связанные с ней функции). Только в этом API есть также поддержка нумерации виртуальных аудиоустройств и аудиоустройств с драйверами в пространстве пользователя.
Не берите данные из файлов, расположенных в /proc/asound/. В этих файлах содержится информация только о звуковых драйверах ядра, подключаемых модулей пространства пользователя там нет. Кроме того, устройства в ядре могут отличаться от их представления в пространстве пользователя (то есть подчиненные устройства могут обозначаться не так, как устройства пространства пользователя, например surround51 и аналогичные).
Не рассчитывайте на стабильность списков устройств в ALSA. На данный момент они зависят от порядка инициализации драйверов во время загрузки и поэтому могут изменяться.
Не используйте API snd_card_xxx(). Для нумерации используйте snd_device_name_hint() (и связанные с ней функции). Функцияsnd_card_xxx() устарела. Она просто перечисляет аппаратные устройства в ядре. Устройства пространства пользователя, такие как звуковые серверы и Bluetooth-аудио не поддерживаются. Функция snd_card_load() на данный момент полностью устарела.
Не задавайте жестко в коде строки устройств, особенно hw:0 или plughw:0, или даже dmix — эти устройства не определяют назначение каналов, они назначены на устройства ядра. Крайне желательно использовать для строк устройств только default. Если требуется особое переназначение каналов, правильной строкой устройств будет front для стерео, surround40 для четырехканального звука 4.0,surround41, surround51 и так далее. К сожалению, на данный момент ALSA определяет стандартные наименования устройств с назначением каналов только для устройств ядра. Это означает, что default можно безопасно применять только для моно- и стереопотоков. Возможно, стоит начинать строки устройств с plug:, чтобы ALSA выполнялось переформатирование, переназначение или конвертация PCM-потока, если устройство или звуковая подсистема не поддерживает требуемые параметры дискретизации.
Не рассчитывайте, что поддерживается какой-либо тип дискретизации кроме U8, S16_LE, S16_BE, S32_LE, S32_BE, FLOAT_LE, FLOAT_BE, MU_LAW и A_LAW.
Не используйте для синхронизации snd_pcm_avail_update(). Эта функция должна использоваться только для запроса количества байт, которое можно считать или записать в данный момент. Не используйте snd_pcm_delay() для запроса уровня заполнения буфера воспроизведения. Эта функция должна использоваться только для синхронизации. Удостоверьтесь, что вы полностью понимаете различие. Помните, что эти две функции возвращают значения, которые не взаимосвязаны непосредственно!
Не рассчитывайте, что в органах управления микшером всегда будет информация об уровне в децибелах.
Не рассчитывайте, что все устройства поддерживают доступ к буферу в стиле MMAP.
Не рассчитывайте, что указатель оборудования в буфере воспроизведения (возможно, с применением mmap) отображает действительную позицию сэмпла в DAC. Могут возникать дополнительные задержки.
Не пытайтесь с помощью собственного кода проводить восстановление после сбоев ALSA, таких как опустошение буфера. Используйте вместо этого snd_pcm_recover().
Не трогайте метрики буферизации и периодов, если нет необходимости выставлять особые задержки. Будьте осторожны в разработке, аккуратно обрабатывая ситуации, в которых подсистема не может выполнить ваши запросы метрик буферизации. Помните, что во многих случаях размер буфера воспроизведения не оказывает непосредственного влияния на общее значение задержки. То есть установка фиксированного размера буфера может на практике привести к гораздо большим задержкам.
Не рассчитывайте, что функция snd_pcm_rewind() доступна и полностью работоспособна.
Не рассчитывайте, что время, когда PCM-поток может получать новые данные, строго зависит от параметров дискретизации и буферизации и от окончательной пропускной способности. Всегда проверяйте, чтобы новые аудиоданные поступали устройству, когда оно их запрашивает, сигнализируя о доступности для записи в fd (и аналогично для захвата).
Не используйте “простой” интерфейс snd_spcm_xxx().
Не используйте функций, помеченных как “устаревшие”.
Не используйте подсистемы timer, midi, rawmidi, hwdep.

Что НАДО делать:

Используйте snd_device_name_hint() для нумерации аудиоустройств.
Используйте snd_smixer_xx() вместо чистого snd_ctl_xxx().
Для синхронизации используйте snd_pcm_delay().
Для проверки уровня заполнения буфера воспроизведения/захвата используйте snd_pcm_update_avail().
Используйте snd_pcm_recover() для восстановления после ошибок, возвращаемых любыми функциями ALSA.
По возможности используйте наибольший поддерживаемый устройствами размер буфера, чтобы минимизировать энергопотребление и для защиты от выпадений звука. Используйте snd_pcm_rewind(), если нужна быстрая реакция на пользовательский ввод.

FAQ
А как насчет ESD и NAS?
ESD и NAS устарели, и как API, и как звуковой демон. Не применяйте их больше в разработке.
ALSA не портируется!
Это неверно! На самом деле библиотека пространства пользователя относительно портируема, в нее даже входит звуковая подсистема для аудиоустройств OSS. Нет реальных причин, мешающих использовать библиотеки ALSA на других Unix-подобных системах.
Для меня важнее всего переносимость! Что делать?
К сожалению, пока нет PCM API, действительно портируемого (то есть на Win32), который можно было бы посоветовать. Описанные выше системы более или менее портируемы, по крайней мере на Unix-подобные ОС. Но это не значит, что для них всех доступны подходящие подсистемы. Если для вас важна переносимость на Win32 и MacOS, возможно, стоит поискать решения, не перечисленные среди рекомендаций выше, либо помочь доработать переносимость необходимых подсистем. Ни одна из систем (за исключением OSS) не привязана жестко к ядру Linux или других Unix-подобных систем.
А как насчет PortAudio?
Не думаю, что PortAudio — хороший API для Unix-подобных операционных систем. Не могу его рекомендовать, но решайте сами.
А почему вы так ненавидите OSS4?
Я ничего не ненавижу. Просто не думаю, что OSS4 — серьезный выбор, особенно для Linux. Под Linux он абсолютно бесполезен, так как есть ALSA.
Вы идиот и ничего не смыслите!
Совершенно верно, не смыслю. Но это не мешает мне давать советы. Ха!
Я создал новый проектик, отлично реализующий уровень абстракций для аудио и мультимедиа!
Извините, но этого недостаточно. Я перечисляю здесь только программы, которые точно подходят и достаточно хорошо поддерживаются.
Заключение
Разумеется, это только базовые рекомендации, которые могут лишь подтолкнуть в верном направлении. В каждом конкретном случае потребности разные, соответственно и не рассмотренные здесь варианты могут быть целесообразными. Только вы сами можете определить, что из написанного мной применимо для вашего приложения.
Здесь упоминались только те программные системы, которые считаются стабильными и были общедоступны на момент написания. Надеюсь, в будущем можно будет рассказать о более уместной и переносимой замене безопасной части функций ALSA. Я собираюсь периодически обновлять этот текст для внесения обновленной информации.
Если вы считаете, что я забыл упомянуть какое-то практическое применение или важный API, напишите мне или оставьте комментарий. Однако полагаю, что выше все изложено достаточно исчерпывающе, и если что-то пропущено, то скорее всего умышленно.
Кроме того, учитывайте то, что я участвую в разработке PulseAudio и libcanberra, а также вношу небольшой вклад в ALSA, GStreamer и некоторые другие из перечисленных систем. Да, я пристрастен.
Да, и пожалуйста, размещайте ссылки на этот материал. Я хочу, чтобы это руководство было широко известно в Linux-сообществе. Спасибо!
Прим.: PCM расшифровывается как импульсно-кодовая модуляция (pulse code modulation) и обеспечивает цифровое представление аналогового сигнала, который дискретизируется (оцифровывается) через равные промежутки времени (с заданной в герцах частотой) и представляется в двоичном виде (с заданной точностью – разрядностью в битах).




]]>
			http://UbuntuLinux.ru/developers/protokoly/linux-sound-api-overview/feed/
		0
		
		
		
		http://UbuntuLinux.ru/developers/protokoly/pop3-protocol-commands/
		http://UbuntuLinux.ru/developers/protokoly/pop3-protocol-commands/#comments
		Sat, 20 Mar 2010 16:27:02 +0000
		
				
		
		

		http://manlinux.org/?p=68
		Читать далее →]]>
				




Команды протокола POP3


Команда
Синтаксис
Описание


STAT
Формат ответа: “+ОК nn mm”, где nn — количество сообщений, mm — их общий объем:

С: STAT
S: +ОК 2 320
В этом примере РОРЗ -сервер сообщает, что в данном почтовом ящике находятся два сообщения общим объемом 320 байт.
После того как клиент успешно прошел процедуру аутентификации в РОРЗ- сервере, и РОРЗ- сервер “закрыл” определенный почтовый ящик только для использования данным клиентом (для тех, кто работал с базами данных, это называется EXCLUSIVE ACCESS LOCK), РОРЗ- сессия переходит в режим TRANSACTION, и клиент может начать работу со своей почтой

Команда STAT (без аргументов) используется для просмотра состояния текущего почтового ящика.
В ответ РОРЗ- сервер возвращает строку, содержащую количество и общий размер в байтах сообщений, которые клиент может получить с РОРЗ- сервера. Сообщения, помеченные на удаление, не учитываются


LIST [msg]
С: LIST

S: +ОК 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
ИЛИ
С: LIST 2
S: +ОК 2 200
ИЛИ
 С: LIST 3
S: -ERR no such message, only 2 messages in maildrop
Команда LIST может передаваться как с аргументом msg — номером сообщения, так и без аргумента.

Если команда содержит аргумент, и сообщение с указанным номером существует, ответом на нее будет “информационная строка”, которая содержит номер сообщения и размер сообщения в байтах. Если аргумент не указан — ответом будет список информационных строк обо всех сообщениях в данном почтовом ящике. Сообщения, помеченные на удаление не фигурируют в этом списке


RETR msg
С: RETR 1

S: +ОК 120 octets
S: <text message>
S: .
Используется для передачи клиенту запрашиваемого сообщения. Аргумент команды — номер сообщения. Если запрашиваемого сообщения нет, возвращается отрицательный индикатор “-ERR”.


DELE msg
С: DELE 1

S: +ОК message 1 deleted
ИЛИ
С: DELE 2
S: -ERR message 2 already deleted
Аргумент команды— номер сообщения. Сообщения, помеченные на удаление, реально удаляются только после закрытия транзакции, на стадии UPDATE.


NOOP
С: NOOP

S: +ОК
Для проверки состояния соединения с РОРЗ- сервером используется команда NOOP . При активном соединении ответом на нее будет положительный индикатор “+ОК”:


RSET

 
С: RSET

S: +OK maildrop has 2 messages (320 octets)
Для отката транзакции внутри сессии используется команда RSET (без аргументов). Если пользователь случайно Пометил на удаление какие-либо сообщения, он может убрать эти пометки, отправив эту команду:


TOP msg n
С ТОР 1 10

S +OK
S <header>
S <blank>
S <message body>
S .
По этой команде пользователь может получить “n” первых строк сообщения с номером “msg”. РОРЗ- сервер по запросу клиента отправляет заголовок сообщения, затем пустую строку, затем требуемое количество строк сообщения (если количество строк в сообщении меньше указанного в параметре “n”, пользователю передается все сообщение).


USER name
С: USER frated

S: -ERR sorry, no mailbox for frated here
ИЛИ
С: USER mrose
S: +OK mrose is a real hoopy frood
Когда РОРЗ -сессия находится в состоянии аутентификации (AUTHORIZATION), и клиент должен зарегистрировать себя на РОРЗ -сервере. Это может быть выполнено либо с помощью команд USER и PASS — ввод открытых пользовательского идентификатора и пароля (именно этот способ используется чаще), либо командой АРОР — аутентификация цифровой подписью, на базе секретного ключа. Любой РОРЗ -сервер должен поддерживать хотя бы один из механизмов аутентификации.

Аргументом — “name” является строка, идентифицирующая почтовый ящик системы. Этот идентификатор должен быть уникальным в данной почтовой системе РОРЗ -сервера. Если ответом на эту команду является строка индикатора “+OK”, клиент может отправлять команду PASS — ввод пароля или QUIT — завершить сессию. Если ответом является строка “-ERR”, клиент может либо повторить команду USER, либо закрыть сессию


PASS string
С: USER mrose

S: +OK mrose is a real hoopy frood
С: PASS secret
S: -ERR maildrop already locked
ИЛИ
С: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: +OK mrose’s maildrop has 2 messages (320 octets)
Аргументом команды является строка пароля данного почтового ящика. После получения команды PASS, РОРЗ -сервер, на основании аргументов команд USER и PASS, определяет возможность доступа к заданному почтовому ящику. Если РОРЗ -сервер ответил “+OK”, это означает, что аутентификация клиента прошла успешно и он может работать со своим почтовым ящиком, т. е. сессия переходит в состояние TRANSACTION. Если РОРЗ- сервер ответил “-ERR”, то либо был введен неверный пароль, либо не найден указанный почтовый ящик


АРОР name digest
S: +OK РОРЗ server ready 1896.697170952@dbc.mtview.ca.us

С: АРОР mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK maildrop has 1 message (369 octets)
Алгоритм на основании открытого ключа “tanstaaf и временной метки
< 1896.697170952@dbc.rnt.view.ca.us> построил шифрованную строку “c4c9334bac560ecc979e5800Ib3e22fb”.
Команда аутентификации пользователя АРОР не входит в список обязательно реализуемых команд РОРЗ -сервера. Эта команда предоставляет значительно больший (по сравнению с командами USER или PASS) уровень защиты аутентификации пользователя при открытии сессии AUTHORIZATION и используется только тогда, когда к обеспечению конфиденциальности доступа к информации почтовых ящиков предъявляются повышенные требования. Эта команда может быть передана клиентом РОРЗ -сервера после получения приветственного сообщения или после ошибки обработки команд USER/PASS.

Аргументами команды являются: name — имя пользователя (то же, что и в команде USER), digest — шифрованная (по алгоритму MD5) строка пароля. Применяемый здесь алгоритм необратимого шифрования для построения секретного ключа использует открытый ключ и временную метку. Временные метки передаются хосту клиента вместе с сообщением приветствия. Например, для UNIX-машин временная метка может иметь вид: <process-ID.clock@hostname>, где process-ID — это идентификатор процесса, clock — состояние таймера на момент установления соединения, hostname — имя компьютера РОРЗ -сервера. Этот механизм позволяет достичь очень высокой степени защищенности. Далее показан пример работы команды АРОР


 QUIT 
С: QUIT

S: +ОК dewey POP3 server signing off
К командам состояния AUTHORIZATION может относиться команда закрытия РОРЗ- сессии — QUIT , если она была отправлена в режиме AUTHORIZATION (например, при вводе неправильного пароля или идентификатора пользователя):

Эта команда отправляется без аргументов и всегда имеет единственный ответ “+ОК”.


Пример сценария работы с POP-сервером


Ниже приведена стандартная сессия работы с РОРЗ -протоколом.

S: <wait for connection on TCP port 110>

C: <open connection>
S: +OK РОРЗ server ready
С: USER mrose
S: +OK mrose is a real hoopy frood
С: PASS secret
S: +OK mrose’s maildrop has 2 messages (320 octets)
С: STAT
S: +OK 2 320
С: LIST
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
С: RETR 1
S: +OK 120 octets
S: <the РОРЗ server sends message 1>
S: .
С: DELE 1
S: +OK message 1 deleted
С: RETR 2
S: +OK 200 octets
S: <the РОРЗ server sends message 2>
S: .
С: DELE 2
S: +OK message 2 deleted
С: QUIT
S: +OK dewey РОРЗ server signing off (maildrop empty)
С: <close connection>
S: <wait for next connection>



]]>
			http://UbuntuLinux.ru/developers/protokoly/pop3-protocol-commands/feed/
		0