Talk:VGM
From Wikipedia, the free encyclopedia
 |
This article is within the scope of WikiProject Video games. For more information, visit the project page, where you can join the project and/or contribute to the discussion. | |
| Stub | This article has been rated as Stub-Class on the assessment scale. | |
|
CVG To-do:
|
||
Contents |
[edit] Cycle accuracy
Sample accuracy is not enough for reproduction of PCM samples used in Sega Genesis VGM files. Cycle accuracy is the bare minimum for proper timing.
At least with GYM, the infrequent timing intervals made it possible to estimate the correct interval for the samples, but sample-accurate timing makes it even more difficult to estimate the exact time of the samples.
I have sample clips of original and VGM versions of the same test clip, and a frequency plot comparing the two. Note that the original clip is not rendered from a GYM, but a VGM produced with 256 times the normal timestamp precision, allowing for more accurate rendering.
Cycle accurate logging allows for cycle accurate playback, either using band-limited sound synthesis, or full supersampling.
[edit] Response
As a co-originator of the VGM format, and currently the sole developer of the official spec, I agree in principle with some of these statements. Storing all data in terms of the highest common clock rate of the sound chips in use - noting that in the Mega Drive, you have the YM2612 at 7.67MHz and the SN76489 equivalent at 3.58MHz - would be the most accurate timing possible. However, tha argument that GYM is more accurate in this respect is nonsensical, its handling of sample starts, rate changes and ends is non-existent and this is a prime reason for the acceptance of VGM by some emulator authors who actively boycotted GYM for its inaccuracy.
The problems that have been encountered over the last few years with the emergence of Mega Drive VGMs and their accurate editing, trimming, looping etc are yet to be resolved. The intended solution would in fact resolve these problems beyond the frame-accurate resampling you suggest, but as with most open-source community-driven projects, there's only one guy developing the code, namely me, and I've got a full-time job, substantial study commitments and a family to take away my precious coding time.
I'll ignore the more extreme parts of your rant which you chose not to give here. I'll just say that VGM is what it was intended to be, a logging format accurate to 44100Hz instead of 60Hz, and criticism that it isn't X or Y is kind of irrelevant, especially in the face of the fact that it's open for enhancement.
-- Maxim
[edit] Further response
It seems I was a bit hasty posting that. While I was a bit out of sorts at the time, I have come to realize that at least cycle accuracy would probably produce even larger files than with sample accuracy. Slightly higher accuracy would probably have less of an effect on file size than cycle accuracy.
In retrospect, I should not have added this to my long list of stirring up crap by spreading what was more of a personal outlet than any public complaint, as the original message was probably only seen by myself, and maybe one or two other people.
As a final comment by the original author, "Sorry for the rant. It was not meant to be publicly posted and was based on annoyance with claims by others that the VGM format cannot be more accurate."
[edit] Reasons
Why is there VGM when there already is GYM etc.? --Abdull 21:16, 25 August 2006 (UTC)
- In short: because GYM is a bad, obselete and imprecise format. This article and GYM can anwer your question, just take a read. 200.233.244.55 11:14, 2 September 2006 (UTC)
