07673: All: Recorded mng and wav files are out of sync.

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

Flags
Regression Version
Affected Sets / Systems	All

Attached Files	MAME SMS AVI WAV Recroding test.png (83,891 bytes) Jun 3, 2020, 14:51 Uploaded by Hirudov
Attached Files	MAME avi vs mngwavavi vs wav.png (726,661 bytes) Jun 3, 2020, 18:39 Uploaded by Hirudov

No.17708 Tafoid Administrator 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?
No.17709 Hirudov Tester 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] Source: https://www.mamedev.org/releases/whatsnew_0221.txt 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.
No.17710 Tafoid Administrator 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. https://github.com/mamedev/mame/pull/6537 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.
No.17711 Hirudov Tester 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.
No.17712 Tafoid Administrator 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.
No.17713 Hirudov Tester 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.
No.17714 Tafoid Administrator 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?
No.17715 Bletch Developer 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)?
No.17717 Hirudov Tester 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.
No.17719 Tafoid Administrator 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?
No.17720 Bletch Developer 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); }
No.17721 hap Developer 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.
No.17724 Bletch Developer 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.
No.17756 hap Developer 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. http://www.libpng.org/pub/mng/spec/#mng-critical
No.17757 hap Developer 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.