Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
07673 Sound Minor Always Jun 3, 2020, 08:49 Jun 19, 2020, 09:53
Tester Hirudov View Status Public Platform MAME (Official Binary)
Assigned To hap Resolution Fixed OS
Status [?] Resolved Driver
Version 0.221 Fixed in Version 0.222 Build
Fixed in Git Commit Github Pull Request #
Summary 07673: All: Recorded mng and wav files are out of sync.
Description When recording mng and wav files, the produced results are out of sync with different time lengths. Used to work fine until .220, but seems some changes were made in .221, which produces the desync issue. Recording of AVI files still works fine.
Steps To Reproduce It gives the same erroneous result for MAME and MESS systems. For example

mame64 digdug -mngwrite digdug.mng -wavwrite snap/digdug.wav

mame64 sms -mngwrite sms.mng -wavwrite snap/sms.wav

Both of the above command lines will produce video and audio files that are out of sync.
Additional Information Version .220 of MAME doesn't have this issue and produces perfectly synced video and audio files of same time length.
Github Commit
Regression Version
Affected Sets / Systems All
Attached Files
png file icon MAME SMS AVI WAV Recroding test.png (83,891 bytes) Jun 3, 2020, 14:51 Uploaded by Hirudov
png file icon MAME avi vs mngwavavi vs wav.png (726,661 bytes) Jun 3, 2020, 18:39 Uploaded by Hirudov
There are no relationship linked to this issue.
User avatar
Jun 3, 2020, 12:15
I don't have the proper programs to process/merge the MNG/WAV files to make a presentation so that I can visually detect any vsync when compared to an .avi recording. Which one is lagging behind? Is there more video getting ahead of the audio?
User avatar
Jun 3, 2020, 14:27
edited on: Jun 3, 2020, 14:40
Yes, video is longer than the audio. I use AEX MNG2AVI (search it on Google) to process the files. It worked fine until .220. Now with .221 the audio is out of sync and slightly shorter. Probably it has something to do with this update from the changelog:

-Refactored AVI/MNG recording code to move it out of emu/video.cpp and reduce duplication. [Nathan Woods]


P.S. Further test I performed with:
mame64 sms -mngwrite sms.mng -wavwrite snap/sms.wav -aviwrite sms.avi

Comparing the audio track from the avi file with the wav file - there is no desync. Which means the problem is in the mng recorder.

Also the wav file is slightly longer than the avi file audio track. Which means there is some discrepancy between the avi/mng recorder and the wav recorder.
User avatar
Jun 3, 2020, 14:39
edited on: Jun 3, 2020, 14:41
I did testing and made notes in my testing of the code changes as requested that in some instances MNG data sizes for the same machine before and after did differ.

Lacking knowledge and ability to directly examine the MNG files, I couldn't tell if it was inserting data before regular recording or it was recording longer than before, tacking data in at the end. I just had file lengths and hashes to tell me of differences and made attention to that.

Timed run snapshots in my testing were the same in all tested cases as were the WAV file outputs.
User avatar
Jun 3, 2020, 14:43
Further investigation shows there is discrepancy between avi and wav recordings!

Seems the avi recording ends earlier than the wav recording.

See the edits of my post before.
User avatar
Jun 3, 2020, 14:45
I'll assign this to the Dev who worked on the code. If you have some more visual examples or other information about the issue that might be useful to determine possible causes, please post.
User avatar
Jun 3, 2020, 14:54
Okay, I attached a screenshot showing that the wav audio track is longer than the avi audio track. Seems it is not only issue with mng, but also with avi. I didn't investigate it before, was only concerned it is mng/wav discrepancy issue.

If I can help further with tests or reports, I will provide.
User avatar
Jun 3, 2020, 15:18
Ok. Please correct me if I'm wrong but it would appear that .AVI is the bottom line showing extra audio at the end of the recording and seems to match up with -wavwrite otherwise?
User avatar
Jun 3, 2020, 15:25
While this is almost certainly the result of my changes, I'm having trouble gauging what I should be looking for. The act of clicking on an AVI/MNG/WAV seems to produce expected results that to my untrained eye/ears, appear to be correct.

Is there an actual synchronization problem? By this, are the sounds in an AVI or MNG for say, time index 42.42 seconds not lined up with what one hears in the WAV? Or are we seeing a scenario where one of these files is longer or shorter than what we expect (i.e. - a WAV goes for 42 seconds, but the MNG at 60 fps has 2521 frames instead of the expected 2520)?
User avatar
Jun 3, 2020, 18:49
edited on: Jun 3, 2020, 18:58
I've uploaded another screenshot of produced avi mng and wav files. On top is the avi file (2 tracks), on the middle is avi file produced from mng and wav files (2 tracks) and on the bottom is a wav file (1 track). As seen, there is discrepancy and desync between the produced avi file with -aviwrite and the produced avi file from combining mng and wav files. There is also discrepancy between the wav file and the avi file. Additionally there are discrepancies in the video tracks of several frames. I.e. the avi file doesn't match either the wav either the mng produced separately.

For the time being I am switching back to MAME .220, since I am not sure which of the produced video files is the correct one.

Edit: The avi file from -aviwrite reported in properties is 60.00 fps, while the avi file from the mng+wav is 60.61fps. Seems here is the issue.
User avatar
Jun 3, 2020, 19:44
I only still have Windows 7 and even if a make the same length (-str 5), I'm getting "60 frames/second" as the value when I do Right-Click -> Properties -> Details .
Does Windows 10 have more accurate numbers?
User avatar
Jun 4, 2020, 01:06
So after debugging this, I think that I have a fix that restores the old behavior, but this feels like an incorrect fix because this is essentially performing a rounding operation on the frame period (this is based on the behavior of the old MNG code; the old AVI code was even worse). It is possible that this is restoring old behavior that also happens to coincide with an equivalent defect in -wavwrite.

I'm still hampered by my lack of good tools to scrutinize AVI and MNG files for vital characteristics (specific frame counts, timing etc). Hirudov, do you have the ability to compile MAME? If so, could you try giving this patch a run?

diff --git a/src/emu/recording.cpp b/src/emu/recording.cpp
index e7cf3d88678..f4d60b9c3f1 100644
--- a/src/emu/recording.cpp
+++ b/src/emu/recording.cpp
@@ -66,7 +66,12 @@ movie_recording::movie_recording(screen_device *screen)
  : m_screen(screen)
  , m_frame(0)
- m_frame_period = m_screen ? m_screen->frame_period() : attotime::from_hz(screen_device::DEFAULT_FRAME_RATE);
+ // this seems to be a roundabout way to determine the frame period; the original version
+ // of this code took the period directly from the screen object, but then we had MT#7673
+ //
+ // perhaps this logic is only needed to compensate for an equivalent problem in the wavwrite code?
+ int rate = int(screen ? screen->frame_period().as_hz() : screen_device::DEFAULT_FRAME_RATE);
+ m_frame_period = attotime::from_hz(rate);
User avatar
Jun 4, 2020, 19:07
edited on: Jun 4, 2020, 19:08
Is mame.ini unmodified?
When refreshspeed=1, audio will go out of sync with video in digdug after recording.
User avatar
Jun 6, 2020, 11:35
I presume it is. I can't speak for others, but I didn't even know that the "refreshspeed" parameter existed.
User avatar
Jun 18, 2020, 22:28
edited on: Jun 18, 2020, 22:53
Looks like the problem is MNG itself?
It has "Ticks_per_second" in the header, an unsigned integer. In other words: does not support 60.6Hz framerate.
User avatar
Jun 19, 2020, 09:52
It should be fixed now.
Note that recording.cpp m_frame_period is supposed to be the exact mng/avi file frame period, not that of the emulated screen.