| 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 |
 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 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 | |||||
| Flags | |||||
| Regression Version | |||||
| Affected Sets / Systems | -wavwrite (core) | ||||
|
Attached Files
|
 nes_siliusu_wavwrite_compare.7z (1,314,901 bytes) Dec 27, 2014, 17:07 Uploaded by TafoidNES siliusu wavewrite comparison | ||||
 No.11334
Firewave 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, |
|---|