Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
05809 Core Minor Always Dec 27, 2014, 17:07 Dec 29, 2014, 18:54
Tester Tafoid View Status Public Platform
Assigned To Resolution Open OS
Status [?] Acknowledged Driver
Version 0.156 Fixed in Version Build
Fixed in Git Commit Github Pull Request #
Summary MESS-specific 05809: -wavwrite (core): Data output issues
Description When recording -wavwrite, there is a 4 byte area which is written as 00 and not part of the header. It is shown in the 4 bytes direct AFTER the header.
I made this discovery when I started testing save state fitness - running -str 20 runs with save states/resumed -str 20 runs being started and stopped 5 times (Every 4 seconds)
Steps To Reproduce The best test case I could find was to use the NES where there are games which produce audio very shortly after booting and for a long period.

My procedure was as follows:

1. Create a reference -wavwrite from the command-line:
"mess nes siliusu -str 20 -wavwrite full.wav"
This will create the baseline comparison.

2. Run 5 instances of the same game, with a different -wavwrite filename for each, such as
"mess nes siliusu -autosave -str 4 -wavwrite 4.wav"
"mess nes siliusu -autosave -str 8 -wavwrite 8.wav"
"mess nes siliusu -autosave -str 12 -wavwrite 12.wav"
"mess nes siliusu -autosave -str 16 -wavwrite 16.wav"
"mess nes siliusu -autosave -str 20 -wavwrite 20.wav"
This will create 5 .wav files which when the data of those is combined will (or should) match the data of the original recording.

3. With a hex editor or some other means, retain the original -str 20 "full.wav" header and save to a separate file (header.dat). The header is the first 44 (0x2c) bytes at the beginning of each .wav file.

4. Combine the 5 'staggered' wavwrite recordings by deleting entirely the first 44 bytes of each file (4,8,12,16,20.wav) and then merge all the data together as one file.

5. Create a new file which contains the header from the full.wav (header.dat) and the data from 5 recordings. In practice, if everything is working correctly, this result in a file which is identical to the original recording which we'll call "merged.wav"

6. Run a file comparison between the two produced files "full.wav" and "merged.wav"
c:\mamesvn\trunk\WAV_RECORD>fc /b full.wav merged.wav
Comparing files full.wav and MERGED.WAV
000BB82C: DE 00
000BB82D: 12 00
000BB82E: DE 00
000BB82F: 12 00
0017702C: CC 00
0017702D: 01 00
0017702E: CC 00
0017702F: 01 00
0023282C: 5A 00
0023282D: 11 00
0023282E: 5A 00
0023282F: 11 00
002EE02C: 8A 00
002EE02D: E9 00
002EE02E: 8A 00
002EE02F: E9 00

Note that there are 4 bytes which the first sample is supposed to be written (as is filled in the file "full.wav") which when running the staggered autosave recording "merged.wav", the first sample of the 'session' is 4 bytes of "00" instead.
Additional Information
Github Commit
Regression Version
Affected Sets / Systems -wavwrite (core)
Attached Files
7z file icon nes_siliusu_wavwrite_compare.7z (1,314,901 bytes) Dec 27, 2014, 17:07 Uploaded by Tafoid
NES siliusu wavewrite comparison
There are no relationship linked to this issue.
User avatar
Senior Tester
Dec 29, 2014, 18:54
I can verify, that the first "frame" MAME writes is always 00 00 00 00. It has nothing to do with save states. It seems that is writing to the .wav/processing sound data before there is any sound data yet,