Mercurial > veg
comparison README @ 0:b4d1a6e4bbde default tip
*: initial commit and research on the .veg file format
| author | Paper <paper@tflc.us> |
|---|---|
| date | Fri, 17 Oct 2025 19:01:34 -0400 |
| parents | |
| children |
comparison
equal
deleted
inserted
replaced
| -1:000000000000 | 0:b4d1a6e4bbde |
|---|---|
| 1 This is a "playground" for reversing the Vegas Pro ".veg" file format. | |
| 2 | |
| 3 What I've figured out so far: | |
| 4 - The .veg file format has a Wave64-style RIFF structure. | |
| 5 - Each file has one big "riff" chunk; it contains the GUID of the | |
| 6 "riff" chunk, a 64-bit little endian size, and another GUID | |
| 7 defining what the type of the data is. In fact, this exactly | |
| 8 explains WHY my little 'msvpvf' tool was able to get away with | |
| 9 simply overwriting the bytes at 0x18, since that's the GUID | |
| 10 stating whether it is a .vf or a .veg. | |
| 11 - That one big "riff" chunk contains many sub-chunks, which | |
| 12 contain other data. The first of these sub-chunks is a | |
| 13 chunk containing generic header data, for example project | |
| 14 resample settings. All of the others are "list" chunks, | |
| 15 which follow the same format as the "riff" chunk. | |
| 16 - The GUIDs seem to be totally random besides the "riff" and | |
| 17 "list" chunks. | |
| 18 - Any and all strings are stored as UTF-16 little endian | |
| 19 (Windows NT style). |
