Допустим, существует аналог sqlite в мире документно-ориентированной бд. То есть все данные хранятся не в бинарном формате в каталоге какой-то mongodb, а в каталоге твоего приложения в текстовом формате. Но поиск идет по индексам, хранящимся, конечно же, не в текстовом формате, а в бинарном для ускорения. Есть ли сценарии использования такой базы? (2) Есть ли какой-то процент sqlite в web-проектах, которые вы делали?

Где можно найти современный обычный телефон с java и экраном min 320x240?

Что с ним с случилось? http://youtu.be/JEzrtzY4TCI Опасно ли чем то в будущем?

Собственно, сабж. Есть желание, руки желают творить и коммитить, творить и коммитить. Тем более хочу создать что-то полезное и привлекательное для php.

Не осилил до конца найти спецификации по первому фрейму. Вот что нашёл:

1. Общая информация о фреймах - http://mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm
2. VBR File structure - http://www.autohotkey.com/board/topic/26901-mp3-file-structure-howto/

   Variable Bitrate (VBR)
   
   This system was created to minimize file lengths and to preserve sound quality.
   Higher frequencies generally needs more space for encoding (thats why many codecs cut all frequencies above cca 16kHz) and lower tones requires less. So if some part of song doesnt consist of higher tones then using eg. 192kbps is wasting of space. It should be enough to use only eg. 96kbps.
   And it is the principle of VBR. Codec looks over frame and then choose bitrate suitable for its sound quality.
   
   It sounds perfect but it brings some problems:
   If you want to jump over 2 minutes in song, it is not a problem with CBR because you are able simply count amount of Bytes which is necessary to skip. But it is impossible with VBR. Frame lengths should be arbitrary so you have to either go frame by frame and counts (time consuming and very unpractical) or use another mechanism for approximate count.
   If you want to cut 5 minutes from the middle of VBR file (all we know CDs where last song takes 10 minutes but 5 minutes is a pure silence, HELL!) problems are the same.
   Result? VBR files are more difficult for controlling and adjusting. And I dont like feeling that sound quality changes in every moment. And AFAIK many codecs have problems with creation VBR in good quality.
   Personally I cant see any reason why to use VBR - I dont give a **** if size of one CD in MP3 is 55 MB with CBR or 51 MB with VBR. But everybody has a different taste... some people prefer VBR.
   
   
   VBR File Structure
   
   is the same as for CBR. But the first frame doesnt contain audio data and it is used for special information about VBR file.
   
   
   Structure of the first frame:
   
   Byte Content 
   0-3 Standard audio frame header (as descripted above). Mostly it contains values FF FB 30 4C, from which you can count FrameLen = 156 Bytes. And thats exactly enough space for storing VBR info.
   This header contains some important information valid for the whole file:
   - MPEG (MPEG1 or MPEG2)
   - SAMPLING rate frequency index
   - CHANNEL (JointStereo etc.) 
   
   4-x Not used till string "Xing" (58 69 6E 67). This string is used as a main VBR file identifier. If it is not found, file is supposed to be CBR. This string can be placed at different locations according to values of MPEG and CHANNEL (ya, these from a few lines upwards): 
   36-39 "Xing" for MPEG1 and CHANNEL != mono (mostly used) 
   21-24 "Xing" for MPEG1 and CHANNEL == mono 
   21-24 "Xing" for MPEG2 and CHANNEL != mono 
   13-16 "Xing" for MPEG2 and CHANNEL == mono 
   
   After "Xing" string there are placed flags, number of frames in file and a size of file in Bytes. Each of these items has 4 Bytes and it is stored as 'int' number in memory. The first is the most significant Byte and the last is the least.
   
   --------------------------------------------------------------------------------
   Following schema is for MPEG1 and CHANNEL != mono: 
   40-43 Flags
   Value Name Description 
   00 00 00 01 Frames Flag set if value for number of frames in file is stored 
   00 00 00 02 Bytes Flag set if value for filesize in Bytes is stored 
   00 00 00 04 TOC Flag set if values for TOC (see below) are stored 
   00 00 00 08 VBR Scale Flag set if values for VBR scale are stored 
   All these values can be stored simultaneously. 
   
   44-47 Frames
   Number of frames in file (including the first info one) 
   
   48-51 Bytes
   File length in Bytes 
   
   52-151 TOC (Table of Contents)
   Contains of 100 indexes (one Byte length) for easier lookup in file. Approximately solves problem with moving inside file.
   Each Byte has a value according this formula:
   (TOC[i] / 256) * fileLenInBytes
   So if song lasts eg. 240 sec. and you want to jump to 60. sec. (and file is 5 000 000 Bytes length) you can use:
   TOC[(60/240)*100] = TOC[25]
   and corresponding Byte in file is then approximately at:
   (TOC[25]/256) * 5000000
   
   If you want to trim VBR file you should also reconstruct Frames, Bytes and TOC properly. 
   
   152-155 VBR Scale
   I dont know exactly system of storing of this values but this item probably doesnt have deeper meaning. 
   
   
   Complicated? Ya, that is. 

3. Вот тут ещё что-то про Lame тег - http://gabriel.mp3-tech.org/mp3infotag.html

   Please, need help.