vgmrips

The forum about vgm files
It is currently 2018-05-26, 4:08:44

All times are UTC + 1 hour [ DST ]




Post new topic Reply to topic  [ 53 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
 Post subject:
PostPosted: 2017-11-24, 0:49:13 

Contributors Contributors
Offline
User avatar

Joined: 2015-02-22, 3:40:22
Posts: 115
Some comments / thoughts about stream commands.

Firstly, the stream commands currently seem to support one stream per chip, and do not specify which register to write to. I think each stream should be assigned an ID which should be referred in the playback commands.

Secondly, for $30 (Set sample format) the term “channel” is pretty vague to me. IMO it should be really generic, specifying a VGM command prefix for the data, sample data length and sample data increment (to support interleaving). Then I can just forward it directly to the player’s processing loop which will take care of the rest, no matter what chip it is for.

Third, it would be good if command $30 was required to be specified in the “initialisation section” block (previously known as the memory data section). No need to change stream IDs / format at runtime I think.

Lastly, I wonder what’s the idea for YM2612-like direct PCM writes?

They can be played with stream commands, however this is maybe too exact, I would imagine on e.g. Z80 there are deviations (how much?). On the one hand, the increased precision will sound better, and the commands are compact. On the other hand imperfections in the original aren’t captured, and the VGM preparation is more complicated. Is this ok?

The obvious alternative is no special processing, which is the cleanest solution if it weren’t for memory use; four bytes per PCM data byte (incl. wait) where it has one now. A “manual advance” could be hacked onto chips to make it three, by allowing data value to be omitted (implying read from stream). But I’m not sure if that’s worth the trouble, to be honest I’m not thrilled by the huge memory footprint of the PJ2612 VGMs, much less three times as much.

What are your thoughts?


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-24, 13:11:57 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 606
From what I've seen, ADPCM streaming happens at a fixed rate, which is a division of a clock frequency. So for OKI 6258, you have 4MHz or 8MHz divided by 512, 768, 1024 so you get 5 different sampling frequencies, though the data bytes contain two samples each, so you'd write at half that rate. Either way, if you store the stream frequency as a fraction of integers, so I guess two 32-bit ints, it would be quite exact. Then, in the player code, you could find the greatest common factor and simplify that fraction, and you'd have to add the player's sampling frequency to the equation, and you'd end up with something like a rate of 15625 / 44100, 31250 / 132300, 15625 / 88200 and so on, if my calculations are correct, and even those can be further simplified. You can then use a combination of numerator, denominator and remainder to simulate the stream's clock without any worries about integer overflow. This is similar to fixed point math, but instead of dividing by a power of two, you're dividing by something more relevant precise.

Anyway, this method works fine and perfectly precise for ADPCM streaming on the 6258, I don't know about other chips. I suppose, ideally, you could store yet another field that dictates how the data in the stream frequency field is stored: as an integer ratio, as a floating point number, as a double, fixed-point (which is still just a fraction, but the denominator is a power of two) etc. A double precision floating point value would take the same space as two 32-bit ints btw.

_________________
Support me on patreon!.
Follow me on twitter.

If you like this post, give it a big thumbs up and hit that subscribe button down below! And as always, thanks for reading, and see you next post.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-24, 22:37:03 

Contributors Contributors
Offline
User avatar

Joined: 2015-02-22, 3:40:22
Posts: 115
Well, ideally PCM streaming would happen at an exact rate. But in practice there will be some jitter, a DMA controller needs to wait for bus access, and especially for CPU-controlled streaming like on Z80, it’s hard to stream at a totally perfect rate if you’re also controlling the FM chip and buffering.

So maybe the stream control commands are too exact? Is it important to capture the imprecisions in e.g. Sega MegaDrive games PCM? OTOH I guess the alternative is pretty heavy on the data size (3-4x as much as it is in VGM 1.0, which is already pretty hefty), so maybe we simply do not have the luxury to care about that. Or maybe we shouldn’t even care since it is either barely audible or more pleasant on the ears.

Btw, IMO the streaming commands should specify rate as a period in system clock cycles (as pretty much every sound chip does as well). Currently the 2.0 proposal allows rate to be specified as a Hz frequency or a period in sound chip cycles, but I think the frequency option should go, and the period should use system clock cycles (“chip 0”) rather than sound chip cycles. Since the streaming rate is driven by the CPU clock, it is the most natural unit to use.

Additionally it’s easier to process in the player, because on a system clock period value I need to do zero processing, I can just subtract it from the running counter like I do for regular commands, no division needed to determine the period every time the pitch is changed. Numerator denumerator is even worse, requiring two divisions, at runtime, so occurring frequently. And 32-bit divisions are pretty rough on a Z80.

vampirefrog wrote:
I suppose, ideally, you could store yet another field that dictates how the data in the stream frequency field is stored: as an integer ratio, as a floating point number, as a double, fixed-point (which is still just a fraction, but the denominator is a power of two) etc. A double precision floating point value would take the same space as two 32-bit ints btw.

Please no… :) Let’s just pick the best option instead of being undecisive and making me implement a plethora of ways, half of which take forever to calculate. Also having more than one way to specify rate is pretty useless anyway, as a user how do I know which I’m supposed to use. If one really must, a fixed point fractional field could be added to the period, which can easily be ignored by the player. But given how streaming is tied to the CPU clock, it doubt it would add actual precision, unless the original streaming code also used fixed point.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-25, 1:31:24 

Contributors Contributors
Staff Staff
Offline
User avatar

Joined: 2013-07-17, 23:32:39
Posts: 293
grauw wrote:
Btw, IMO the streaming commands should specify rate as a period in system clock cycles (as pretty much every sound chip does as well). Currently the 2.0 proposal allows rate to be specified as a Hz frequency or a period in sound chip cycles, but I think the frequency option should go, and the period should use system clock cycles (“chip 0”) rather than sound chip cycles. Since the streaming rate is driven by the CPU clock, it is the most natural unit to use.


This will break compatibility with existing VGMs when converted to the new format. We use Hz because the generic tools that create the PCM streams simply don't care about the main CPU frequency or dividers. We just look at the average write frequency and make a Hz assumption from that.

The way data is streamed vary a bit between systems. Some systems may use DMA, some use FIFO buffers (PWM) and some just use CPU manually timing everything (YM2612)

MD is generally not suitable for DAC streams unless the YM2612 timer was used and the write frequency is constant (with some jittering). Examples being Echo and GEMS. SMPS games usually use a tight Z80 loop to time the samples and for those the actual frequency will vary depending on CPU load (and even the VDP load for the MD). The frequency averaging algorithm used in dacopt does not work well for these games, so the old way of seeking and single byte read commands work better. (although at a size cost)


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-25, 18:01:16 

Contributors Contributors
Offline
User avatar

Joined: 2015-02-22, 3:40:22
Posts: 115
I see, thanks for the information.

ctr wrote:
grauw wrote:
Btw, IMO the streaming commands should specify rate as a period in system clock cycles


This will break compatibility with existing VGMs when converted to the new format. We use Hz because the generic tools that create the PCM streams simply don't care about the main CPU frequency or dividers. We just look at the average write frequency and make a Hz assumption from that.


Hm, ok… I think if you use period with a fixed point fraction, it should be precise enough to convert from Hz.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-30, 8:43:06 

Contributors Contributors
Offline

Joined: 2016-11-04, 14:15:48
Posts: 55
I will post a new draft during the weekend that incorporates some of the recent points.

I will insist however on allowing the sample rate to be specified both in Hz and chip clocks, as that allows for maximum precision for different applications at the bearable cost of one additional division operation. I will also insist that both data block and stream commands, how ever they will look like in the final version, are simpler than in the VGM v1 specification. The "stream ID" in particular is one aspect that I would like to completely get rid of, if at all possible.

I also tend to come down on the side of making VGM2 authoring easier while being precise at the expense of increased player complexity as long as the format does not demand impossible things from hardware players.


Top
 Profile  
 
 Post subject:
PostPosted: 2017-11-30, 13:42:37 

Contributors Contributors
Offline
User avatar

Joined: 2015-02-22, 3:40:22
Posts: 115
Looking forward!


Top
 Profile  
 
 Post subject:
PostPosted: 2018-05-05, 15:03:35 

Staff Staff
Programmers Programmers
Contributors Contributors
Ball Fondlers Ball Fondlers
Offline
User avatar

Joined: 2014-01-28, 5:51:54
Posts: 606
Might I suggest that "VGM" or "Video Game Music" does not necessarily imply sound chips, and does not limit itself to chiptune era music. Current day full orchestra sound tracks are also video game music, and they have nothing to do with sound chips, except, perhaps, if they used a DX7 or something.

Technically, the VGM format is a list of commands to be written to sound chips, plus timing info. It also does not imply that it is a log. A VGM file is not necessarily a log of commands captured from an emulator or from hardware, it is simply a list of commands and timing. It also does not imply to be a video game specific format, it can apply to any hardware, real or emulated, where there is writing to sound synthesis chips. You could, however, make the argument that it's specific to the 8 bit and 16 bit era.

In fact, now that I think about it, VGM files are not specific to Video, Games, Video Games or Music. You could make the argument that usually it's music, but it can also be sound fx or just chip initialization.

But either way, I might make a few nerdy suggestions:

.SCL Sound Chip Log,
.SCM Sound Chip Music,
.CM Chip Music,
.CT Chip Tune (technically incorrect though),
.SCB Sound Chip Bus,
.SCC Sound Chip Capture or Sound Chip Commands,
.CC Chip Capture or Chip Commands,
.SCW Sound Chip Writes,
.CW Chip Writes,
.CWL Chip Write Log,
.CL Chip Log,
.SWL Sound (chip) Write Log,
.AL Audio Log,
.AWL Audio Write Log,
.CAL Cpu Audio Log,
.CCL Chip Command List,
.ACC Audio Chip Commands,
.SL Sound Log,
.SC Sound Commands,
.SOC SOund Commands,
.CHIPC CHIP Commands,
.CHI All pervasive energy, part of every living thing,
.COC COmmands for Chips,
.MCC Music Chip Commands,
.MUC MUsic Commands,
.CUM Chip Unified Music
.CHM CHip Music

_________________
Support me on patreon!.
Follow me on twitter.

If you like this post, give it a big thumbs up and hit that subscribe button down below! And as always, thanks for reading, and see you next post.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 53 posts ]  Go to page Previous  1, 2, 3, 4

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group