Sound Files Editing (VCE)

[llm]

As for the contents. There is not more to it than the wiki says. Its just a list of base instrument sounds. No melody or anything.
How the sound is build up is something zapper can tell you more about.

is there interest in a small console tool or something that shows the info from the VCE file? then we can fill the wiki gaps

[Daniel3D]

O yes. That would be cool.
All you can see now is the chunk name and you can see the raw data in stressed.
I suspect that the 100 Bytes of instrument data is some kind of waveform. Some graphics representation would help in analysis.

[Daniel3D]

As for the contents. There is not more to it than the wiki says. Its just a list of base instrument sounds. No melody or anything.
How the sound is build up is something zapper can tell you more about.

is there interest in a small console tool or something that shows the info from the VCE file? then we can fill the wiki gaps

But I don't really know what there is left to discover.

The files are a bit messy with crap behind the last chunk that is total rubbish and can be removed without trouble.

[llm]

i've wrote a small vce dump tool that reads the header and instrument data + printing (i've got no detailed information about the instrument data - so just printed a hex dump)

https://pastebin.com/e2xJ5S2s

The files are a bit messy with crap behind the last chunk that is total rubbish and can be removed without trouble.

this chunk stuff can also happen in between because the offsets to the instrument data is not always gap-free

TODOs:
-understand the lenFile field
-more details for the instrument data output
-understand the last chunk - not crashing if that is revemoved does not mean its correct or error free to do it

VS2017 cpp exe attached + source

[Daniel3D]

-understand the last chunk - not crashing if that is revemoved does not mean its correct or error free to do it

That is true.
I based my opinion on (my) logic and intuition. That is indeed not a fact.

Contrary to my assumption is data from Mario's.

The CRAS chunk in the middle is the same as the one that stunts has at the end.
I believe that they copied the chunk with the rubbish data to this file. Or it may still be real data.
I don't know. Looks inconsistent.

[llm]

no its very consistent

the offset table of some VCEs can leave gaps between instrument-data-chunks - every bytes block that is not located by the offset-table is dirt which is not needed (like unadressed memory)

can maybe happen if the tools that were used to create the files allowed insert/remove/delete or something

the ADENG1.VCE from Mario is the only file i've found so far that contains also in between the instrument-data-chunks unused blocks
that means the instrument-data offsets are not consecutive but there are just unused space

so copying data from one file with gaps into a file without gaps will just don't work

but its very easy to write a tool that allows a clean recreation/merging of VCE file content, as long as we find out how this lenFile field gets its value (i don't think is the file length or something - maybe last size...)

do someone know if the chunks get only addressed by the 4 byte name or is the position (logical nr, not fileoffset) in the chunk-table relevant?

Code Select Expand


file: F:\projects\fun\dos_games_rev\stunts_drvs_tests\vce_dump\test\mario\adeng1.vce, size: 1784 bytes
  lenFile: 1784
  numInstruments: 14
-->header-size: 118
  title
    [0] = BLOW
    [1] = BUMP
    [2] = CRAS
    [3] = CRs2
    [4] = FORM
    [5] = INDY
    [6] = MODD
    [7] = PRTO
    [8] = SCRA
    [9] = SKID
    [10] = SPNT
    [11] = STAR
    [12] = STOK
    [13] = STOP
  offInst
    [0]: 300
    [1]: 600
    [2]: 700
    [3]: 1566
    [4]: 1466
    [5]: 1266
    [6]: 1366
    [7]: 1166
    [8]: 500
    [9]: 400
    [10]: 1066
    [11]: 100
    [12]: 200
    [13]: 0
offsets always advancing: no
  Instr
    [0] lenInst: 100 (0x64)
    [1] lenInst: 100 (0x64)
    [2] lenInst: 100 (0x64)
    [3] lenInst: 100 (0x64)
    [4] lenInst: 100 (0x64)
    [5] lenInst: 100 (0x64)
    [6] lenInst: 100 (0x64)
    [7] lenInst: 100 (0x64)
    [8] lenInst: 100 (0x64)
    [9] lenInst: 100 (0x64)
    [10] lenInst: 100 (0x64)
    [11] lenInst: 100 (0x64)
    [12] lenInst: 100 (0x64)
    [13] lenInst: 100 (0x64)
expected-offset 100
given-offset 100

expected-offset 200
given-offset 200

expected-offset 300
given-offset 300

expected-offset 400
given-offset 400

expected-offset 500
given-offset 500

expected-offset 600
given-offset 600

expected-offset 700
given-offset 700

expected-offset 800
given-offset 1066
GAP
  0000:  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ...

expected-offset 1166
given-offset 1166

expected-offset 1266
given-offset 1266

expected-offset 1366
given-offset 1366

expected-offset 1466
given-offset 1466

expected-offset 1566
given-offset 1566

Instrument data
[0]
  0000:  64 00 01 00 00 00 00 00 00 00 00 00 FE 00 00 7F E1 00 00 00 00 00 00 00 00 00 00 00 00 0F 00 0F d...............................
  0020:  00 0F 19 00 00 00 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
  0040:  00 02 00 00 00 06 0F 00 00 00 00 00 00 00 00 00 00 00 0F 04 0E 04 00 00 00 00 00 00 00 00 00 00 ................................
  0060:  00 00 00 00                                                                                     ....
[1]
  0000:  64 00 01 00 00 00 00 00 00 00 00 00 00 03 00 7F EF 00 00 00 00 00 00 00 00 00 00 00 00 0F 00 0F d...............................
  0020:  00 0F 80 00 00 0F 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
  0040:  00 02 00 00 00 04 07 08 0F 04 00 00 00 00 00 01 01 00 09 00 02 07 00 00 01 00 00 00 00 00 00 00 ................................
  0060:  00 00 00 00                                                                                     ....
[2]
  0000:  64 00 01 00 00 00 00 00 00 00 00 00 FC 00 00 0C C7 00 02 00 00 00 00 00 00 00 00 00 00 0F 00 0F d...............................
  0020:  00 0F 16 00 00 00 16 00 00 01 00 00 FF 7F 01 00 01 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ................................
  0040:  00 00 00 00 00 07 0A 00 00 01 00 00 03 00 00 00 00 00 0A 0F 00 03 01 00 07 01 00 01 00 00 00 00 ................................
  0060:  00 00 00 00                                                                                     ....
[3]
  0000:  64 00 01 00 00 00 00 00 00 00 00 00 FC 00 00 0C C9 00 02 00 00 00 00 00 00 00 00 00 00 0F 00 0F d...............................
  0020:  00 0F 16 00 00 00 16 00 00 01 00 00 FF 7F 01 00 01 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ................................
  0040:  00 00 00 00 00 07 0A 00 00 01 00 00 03 00 00 00 00 00 0A 0F 00 03 01 00 07 01 00 01 00 00 00 00 ................................
  0060:  00 00 00 00                                                                                     ....
[4]
  0000:  64 00 01 00 00 00 00 00 00 00 00 00 FA 00 0B 00 00 00 02 00 00 00 00 00 00 00 00 00 00 0F 00 0F d...............................
  0020:  00 0F 00 06 40 0B 2A 00 90 00 00 00 FF 7F 0F 00 0B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....@.*.........................
  0040:  00 00 00 00 00 07 0F 07 00 0F 16 00 03 00 01 00 00 00 0F 00 00 0F 02 00 00 00 01 00 00 03 00 00 ................................
  0060:  00 00 00 00                                                                                     ....
[5]
  0000:  64 00 01 00 00 00 00 00 00 00 00 00 FA 00 0B 00 00 00 02 00 00 00 00 00 00 00 00 00 00 0F 00 0F d...............................
  0020:  00 0F 00 06 40 0B 2A 00 90 1F 00 00 22 21 AC FF 00 00 00 00 02 85 00 00 00 00 00 00 00 00 00 00 ....@.*....."!..................
  0040:  00 00 00 00 00 FF 0F 07 00 0F 1C 00 04 00 01 00 00 03 0F 00 00 0F 03 00 05 00 01 00 00 03 00 00 ................................
  0060:  00 00 00 00                                                                                     ....
[6]
  0000:  64 00 01 00 00 00 00 00 00 00 00 00 FA 00 0B 00 00 00 02 00 00 00 00 00 00 00 00 00 00 0F 00 0F d...............................
  0020:  00 0F 00 06 40 0B 2A 00 90 00 00 00 FF 7F 0F 00 0B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....@.*.........................
  0040:  00 00 00 00 00 07 0F 07 00 0F 16 00 03 00 01 00 00 00 0F 00 00 0F 02 00 00 00 01 00 00 03 00 00 ................................
  0060:  00 00 00 00                                                                                     ....
[7]
  0000:  64 00 01 00 00 00 00 00 00 00 00 00 FE 00 0B 00 00 00 02 00 00 00 00 00 00 00 00 00 00 0F 00 0F d...............................
  0020:  00 0F 00 06 40 0B 2A 00 90 1F 00 00 22 21 AC FF 00 00 00 00 02 85 00 00 00 00 00 00 00 00 00 00 ....@.*....."!..................
  0040:  00 00 00 00 00 FF 0F 07 00 0F 16 00 03 00 01 00 00 02 0F 00 00 0F 02 00 00 00 01 00 00 03 00 00 ................................
  0060:  00 00 00 00                                                                                     ....
[8]
  0000:  64 00 01 00 00 00 00 00 00 00 00 00 FC 00 00 0C C9 00 02 00 00 00 00 00 00 00 00 00 00 0F 00 0F d...............................
  0020:  00 0F 00 01 00 00 00 01 00 01 00 00 FF 7F 01 00 01 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ................................
  0040:  00 00 00 00 00 06 0F 00 00 00 00 00 00 00 00 00 00 00 0F 0F 00 00 06 00 01 01 00 01 01 00 00 00 ................................
  0060:  00 00 00 00                                                                                     ....
[9]
  0000:  64 00 01 00 00 00 00 00 00 00 00 00 FC 00 00 7F 00 00 02 00 00 00 00 00 00 00 00 00 00 0F 00 0F d...............................
  0020:  00 0F 00 06 40 0B 2A 00 90 00 00 00 FF 7F 05 00 06 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ....@.*.........................
  0040:  00 00 00 00 01 06 0F 07 00 0D 00 00 04 00 01 00 00 03 0F 00 00 0F 07 00 04 00 01 01 01 00 00 00 ................................
  0060:  00 00 00 00                                                                                     ....
[10]
  0000:  64 00 01 00 00 00 00 00 00 00 00 00 FE 00 0B 00 00 17 02 00 00 00 00 00 00 00 00 00 00 0F 00 0F d...............................
  0020:  00 0F 00 06 40 0B 2A 00 90 1F 00 00 22 21 AC FF 00 00 00 00 02 85 00 00 00 00 00 00 00 00 00 00 ....@.*....."!..................
  0040:  00 00 00 00 00 FF 0F 07 00 0F 16 00 03 00 01 00 00 01 0F 00 00 0F 02 00 05 00 01 00 00 03 00 00 ................................
  0060:  00 00 00 00                                                                                     ....
[11]
  0000:  64 00 01 00 00 00 00 00 00 00 00 00 FC 00 00 7F C9 00 02 00 00 00 00 00 00 00 00 00 00 0F 00 0F d...............................
  0020:  00 0F 00 06 40 0B 2A 00 90 01 00 00 FF 7F 01 00 01 00 00 00 03 91 00 00 FF 7F 02 00 03 0A 07 00 ....@.*.........................
  0040:  00 00 00 00 00 02 0F 07 00 0D 00 00 04 00 01 00 00 03 0F 00 00 05 07 00 04 00 01 01 01 01 00 00 ................................
  0060:  00 00 00 00                                                                                     ....
[12]
  0000:  64 00 01 00 00 00 00 00 00 00 00 00 FE 00 0B 00 00 00 02 00 00 00 00 00 00 00 00 00 00 0F 00 0F d...............................
  0020:  00 0F 00 06 40 0B 2A 00 90 00 00 00 FF 7F 0F 00 0B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ....@.*.........................
  0040:  00 00 00 00 00 07 0F 07 00 0F 16 00 03 00 01 00 00 00 0F 00 00 0F 02 00 00 00 01 00 00 03 00 00 ................................
  0060:  00 00 00 00                                                                                     ....
[13]
  0000:  64 00 01 00 00 00 00 00 00 00 00 00 FC 00 00 7F C9 00 02 00 00 00 00 00 00 00 00 00 00 0F 00 0F d...............................
  0020:  00 0F 00 06 40 0B 2A 00 90 01 00 00 FF 7F 01 00 01 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 ....@.*.........................
  0040:  00 00 00 00 00 02 0F 07 00 04 00 00 04 00 01 00 00 03 0F 00 00 05 07 00 04 00 01 01 01 01 00 00 ................................
  0060:  00 00 00 00                                                                                     ....


attached is version 0.2 of the vce_dump tool + source

[Cas]

What I see in resource files in Stunts in general is that there is no chunk length specification anywhere. What you have is an offset that points to the beginning of the chunk and it's relative to the end of the header, which has a variable length that's 4 + 2 + 4 * (number_of_chunks) + 4 * (number_of_chunks) = 6 + 8 * (number_of_chunks).

This means that, in order to properly get a chunk's data, one needs to know where the next chunk starts and assume that there's no gap between them. For the last chunk, there is no next chunk, so this is what the first field is for: it's supposed to point to the byte after the last byte of the last chunk. The file can be larger, but no chunks can extend past that point.

I deally, chunks should be in order, which simplifies the parsing of the file. This is the case for all the resource files in Stunts that I know of except for original car RES files. Even in disorder, you can sort the chunk positions in memory and guess their lengths as long as the first field is correctly set.

Now, if the length of a field is known in advance because of what it's supposed to carry, for example, if it's supposed to be of a fixed length, like in the case here, in which it seems they're all 100 bytes long, or if the length is specified within the chunk data directly or indirectly, like it happens when listing vertices in the 3D shape resource files, then it may occur that you get more data than you actually need. Stunts may or may not load these extra bytes in memory. I assume it does. I think it's safest to think it that way. So gaps are possible this way.... functional gaps, but probably not content gaps.

[llm]

@CAS

the VCE file toplogy is 100% clear and easy - there is a count for the instrument-data-blocks and all the Instrument-data-blocks are (with my testfiles) of the same size and also got its size included as first field of the data that makes it easy to "calculate" the gaps between the offsets etc. (only occuring in one file so far)
the gaps are just filled full with 0xFF/0x77 that have definitly no relevance for the sound, its easy to get the instrument-data blocks for the specific title

only the content of the instrument-data is unclear (got no documentation or something)

another "problem" (not a big one) is that "lenFile" field (first field in file-header) which is always <= filesize
i have no idea what that field is used for or how it gets calculated
it seem not to follow any regularity trying to calculate it from filesize, headersize, tablesizes combinations.

[Daniel3D]

EDIT:: i wrote part of this post without internet before the 2 posts above, so some information is double. Some is later added response to them. ::/EDIT
As far as I understand, all stunts resources files have the same build-up.
File size / chunk names / chunk offsets
The chunk offsets only give the start position.
The end is the value of the next start position.

So the extra data would give trouble in files with variable chunk sizes. In this case it is not a problem because the game only reads the expected size.

If you remove the corrupted chunk in stressed and replace it with a good one, stressed will update the offsets automatically.

Lenfile is updated to. But I also have no idea if stunts uses it.
Maybe some general tool kept track of that for size management to aid in keeping the game fit for distribution on floppy.

-----
for testing I took the Mario's ADENG1 with the corrupted CRAS chunk, removed that and duplicated the CRs2
(renamed it to CRAS and edited the single different value to be an equal to original CRAS) and saved it again.
now the file looks clean.
You can now see that the file length part (first 4 characters) are updated. but after the chunk names the offset values for the first 3 are the same, the others are also updated. and the start of each sound chunk sarts with | d. .... |

[Daniel3D]

I suspect that the 100 Bytes of instrument data is some kind of waveform. Some graphics representation would help in analysis.

The 100 bitsbytes are sound samples, and I am searching for a way to analyze it or visualize it. I came upon the article below.
Looks like something worth to try, but I don't know for sure.

Understanding Binary Formatted Waveform Data
https://rfmw.em.keysight.com/wireless/helpfiles/n5106a/understanding_waveform_data.htm

[Cas]

Yes, I gave a look at a few of these VCE files and it's true that the first dword does not seem to have a logical value. All other RES files in Stunts follow the simple rule that I tried to describe (that is, by suggesting it probably isn't truly the "file length", but the position where the next chunk should be attached if there were another, so that you know the length of the last chunk; in practice, pretty much the same thing). But even if you understand this field my way, it still doesn't match for VCE files. However, I am feeling that, if you change this to whatever you please, that doesn't affect Stunts. Then the question is why it was generated with that value, but still, we can give it the "right" one. Kind of like why car RES files have their chunks misordered for original cars, but still, the "right" order works.

[llm]

The 100 bits are sound samples, and I am searching for a way to analyze it or visualize it. I came upon the article below.

100 bytes or 800 bits

[llm]

Yes, I gave a look at a few of these VCE files and it's true that the first dword does not seem to have a logical value.

its called "reportedSize" in stressed source code (https://github.com/dstien/gameformats/blob/9827f7c1a88db5bf92f1ac9e752bb3f14bd378b3/stunts/stressed/src/app/resource.cpp#L69)

Code Select Expand

if (reportedSize != fileSize) {
      quint8 compType = reportedSize & STPK_PASSES_MASK;
      ...


but that does also not give a clear logical results ... maybe its just ignored - its time to analyse the VCE reader code in restunts

[llm]

If you remove the corrupted chunk in stressed and replace it with a good one, stressed will update the offsets automatically.

i can't find the coed place in stressed were the VCE file gets rewritten - do you use the raw edit? that just seems to write the bytes that gets loaded to the file - no re-ordering or setting of the offset-table - but im not a stressed pro

[llm]

the VCE handling in restunts is in seg027.asm

function:
  init_audio_resources
    parameter:
       var_titlptr - for the title string
       arg_vcefileptr - for the VCE file content (i think)
  audioresource_find
  audio_map_song_instruments
  audio_map_song_tracks
  load_voice_file <--

  this one seg008.asm loads the file + title - best candidate for a detailed analysis
     file_load_audiores