It is currently Fri Nov 17, 2017 12:28 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 51 posts ]  Go to page 1, 2, 3, 4  Next
Author Message
PostPosted: Mon Mar 28, 2016 7:43 pm 
Offline
User avatar

Joined: Fri Sep 02, 2011 8:34 pm
Posts: 476
*From my perspective* - I am adding a new feature to SNES Tracker Debugger (STD) today, and it's SPC Export. Now, some of you might know I'm using my own modified version of Blargg's GameMusicEmu (GME) called libgme_M for this. Blargg has some funny comments in his code for "decoding" SPC fields -- and his frustration with the format is evident. (multiple comments)

Let's refer to some of the "best" SPC documentation I could ever find


I'm assuming this is the end-all be-all for SPC documentation. Someone please comment if you know better.

One of the most obvious issues with the SPC format is an unclear distinction between a "text" SPC and a "binary" SPC -- why there exists both a text and binary form in the first place is beyond me.

Then there's the actual string fields, which are "text" in both the "text" and binary versions of the SPC format -- is this ASCII text only? Do people stick Unicode-16 in there? Should I support that? But since I only plan on supporting ASCII in the first release anyways, that's all I'll do.

Continuing on the text-fields -- I suppose it's unsafe to assume they are null-terminated.. (Duh! *slap* goes the professional). I'm not sure if GME makes this assumption or not, yet!

Another issue is the "emulator" field -- which takes of all things, a number! But, only a few emulator indices were ever documented, and since this format is not at all regularly updated or kept standardized -- it's a crapshoot whether numbers are overlapping or not, or what owns which number. In this kind of non-standardized environment, a text field would have probably been best for this.

---------

If anyone has an SPC they know is distinctly a text one, or a binary one, I'd like your sample please.

Didn't Kevtris make some kind of new format that *might* be related to this?

Can I just go ahead and make a new format that is less difficult to work with?

---------

To the creator of SPC file format - I know how it is. We live and learn. Sometimes, looking back, we see what we've created and go *facepalm*

_________________
SNES Tutorials (WLA DX)
SNES Memory Mapping Tutorial (Universal / LoROM) -- By Universal I introduce how memory mapping works, rather than just provide a LoROM map.
SNES Tracker (WIP) - Music/SFX composition tool / SPC Debugger


Top
 Profile  
 
PostPosted: Mon Mar 28, 2016 8:20 pm 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
SPC is complete and utter shit. But it was the first out the gate, and no amount of improvements will ever convince anyone to switch. See: IPS, CHT, SMC, ZIP, WLA-DX, etc.

> Can I just go ahead and make a new format that is less difficult to work with?

I made a vastly superior format named SFM (Super Famicom Music), but we got bogged down because a true state capture has internal variables, and different emulators will want to name those fields differently (they definitely don't have official names.) Some emulators won't even support certain state fields, others may require new ones not yet known for a perfect capture. Forking the format with emulator-specific sections is the worst possible thing you can do.

SPC can't handle streaming audio (Tales of Phantasia opening, etc) because it's merely a snapshot of the SMP+DSP; and SNSF requires ROM hackers to create because they're literally butchered SNES ROMs that try to remove as much as possible except for the music code (and this forces you to emulate the CPU and possibly PPU just to play music.)

So here's the key to a much better format: when ripping the music track, log all the values read from $f4-f7 on the SMP to the end of the file. Remove the data for non-streaming tracks if you want (it'll compress down to nothing anyway), and leave it for streaming tracks. Timing of the accesses doesn't need to be logged, nor does the addresses. Just a linear stream of all bytes read, and then play back those accesses sequentially when playing the music. This can easily result in consistent playback because we have cycle-perfect timing of the SMP and DSP now. We ripped Tales' opening song in like 200KiB, whereas regular songs were the same ~68KiB of regular SPCs.

But good luck with the bike-shedding on how to store the internal state of the SMP/DSP. And enjoy the frustration as you spend the next ten years trying to convince everyone to use your much better format to absolutely no avail because "SPC is good enough."


Top
 Profile  
 
PostPosted: Mon Mar 28, 2016 8:40 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3100
Location: Nacogdoches, Texas
bazz wrote:
(STD)

:|


Top
 Profile  
 
PostPosted: Mon Mar 28, 2016 8:58 pm 
Offline
User avatar

Joined: Fri Sep 02, 2011 8:34 pm
Posts: 476
byuu wrote:
SPC is complete and utter shit. But it was the first out the gate, and no amount of improvements will ever convince anyone to switch. See: IPS, CHT, SMC, ZIP, WLA-DX, etc.


It's funny you mentioned WLA-DX .. I even switched once to ca65 and then *went back* to WLA DX. I think I am masochistic these days, which could probably be why I'm good at any of this stuff.

Quote:
I made a vastly superior format named SFM (Super Famicom Music), but we got bogged down because a true state capture has internal variables, and different emulators will want to name those fields differently (they definitely don't have official names.)


Who is "we"?

Quote:
SPC can't handle streaming audio. So here's the key to a much better format


I love that you considered streaming audio in your format.

Quote:
But good luck with the bike-shedding on how to store the internal state of the SMP/DSP. And enjoy the frustration as you spend the next ten years trying to convince everyone to use your much better format to absolutely no avail because "SPC is good enough."


I feel your personal pain (ie .sfc).

Now I could get into further details of why I feel your better file format(s) or tool(s) did not gain popularity, or why I want to know why no timing info was needed to log the CPU->SPC writes, but I already have a super-high pile of issues I'm sorting through. If anything, I learned that I am probably *not* the guy to introduce a new SPC format, because you've shown me the 2 crucial changes it should require:

  • Streaming Support
  • Some sort of *new* internal state issue you've mentioned (which I don't see how the traditional SPC logging of this information doesn't already have this covered). I know some emu's can have *better* state recording but the minimum that SPC already provides seems sufficient and relieves us of additional complexity to the format.

Unfortunately, since I don't give a damn about streaming -- only because the rest of the tracker software isn't written -- I'm already flawed to write a good new format...

But damn, I'm intrigued, and I think I could do it -- so please, byuu, answer these questions:

for Streaming -- Why is it safe to assume no timing info needs to be logged? Isn't that making an assumption that all data being written is at the earliest possible moment? The assumption might suit a lot of test cases, or all of them, but this is definitely an assumption! Unless you school me.

Can you agree with me to leave out emulator-specific state and just leave in traditional SPC state, namely DSP vals, CPU reg vals, and RAM snapshot.

Of course, even if I/we make a new format, SNES Tracker will support SPC as well!

Even if we *can* agree on the basis for a new format, I will probably want to concentrate on SPC support and the rest of my tracker software first just to get it up and running!

This has been a really helpful topic so far! Thanks for getting involved!

_________________
SNES Tutorials (WLA DX)
SNES Memory Mapping Tutorial (Universal / LoROM) -- By Universal I introduce how memory mapping works, rather than just provide a LoROM map.
SNES Tracker (WIP) - Music/SFX composition tool / SPC Debugger


Top
 Profile  
 
PostPosted: Mon Mar 28, 2016 9:14 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3100
Location: Nacogdoches, Texas
Well, if you're making the tracker software, what do you really need to worry about streaming for? Assuming you're streaming to replace instruments mid song or something, when designing the song in the tracker, you'd have it play the incorrect instruments but they're in the right spot to where they're going to be overwritten in the actual game. If the APU can't do anything about it because it's the CPU's job, (like streaming) then why would it have to be in the tracker? It might sound weird in the tracker, but it'll work fine. I guess you could create a "stream" function in the tracker that just changes instrument data for the sake of hearing how it sounds, but it won't affect the final output.


Top
 Profile  
 
PostPosted: Mon Mar 28, 2016 9:15 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 800
bazz wrote:
I want to know why no timing info was needed to log the CPU->SPC writes

Because it's not logging writes. It's logging reads. They happen when they happen.

I didn't know SNSF required a whole-system emulation. I kinda thought it must be logging timestamped writes, but I didn't think of the above idea because I didn't think it through.

I do wonder if it would take more or less space to log timestamped writes instead of bare reads (one imagines that reads outnumber writes), but the emulation requirements would then be more finicky. Logging reads dispenses with the need to care about timing at all.


Top
 Profile  
 
PostPosted: Mon Mar 28, 2016 10:13 pm 
Offline
User avatar

Joined: Fri Sep 02, 2011 8:34 pm
Posts: 476
Espozo wrote:
bazz wrote:
(STD)

:|


Yeah, I planned that.

Espozo wrote:
Well, if you're making the tracker software, what do you really need to worry about streaming for?


Creating a new SPC file format transcends SNES Tracker. I would be foolish to create a new SPC file format that does not address these general needs that the first format did not live up to.

SNES Tracker doesn't appear to require streaming support - most general streaming situations will not require direct involvement with the tracker -- but even if a situation were dreamt up, I would not support it in the first release.

The SPC debugger *should* support streaming. Any supporting APU emulator would also require the following additions:

  • APU "stream playback" feature - stream the new file-format's "stream content" as SPC reads from $f4-$f7.

Of course, after a format is defined, someone like Byuu would be most fit for writing in the new SPC export feature, while someone like me could write the new SPC Import feature, and then we'd have a working prototype.

93143 wrote:
bazz wrote:
I want to know why no timing info was needed to log the CPU->SPC writes

Because it's not logging writes. It's logging reads. They happen when they happen.


Ohhhhhh! :)

93143 wrote:
I do wonder if it would take more or less space to log timestamped writes instead of bare reads (one imagines that reads outnumber writes), but the emulation requirements would then be more finicky. Logging reads dispenses with the need to care about timing at all.


In the read strategy, depending on the regular amount of consecutive repeated values - doing a "value,repetitions" pattern could be efficient. But compared to real compression solutions, this might be a joke. I'm not well educated in compression. Please someone school me.

But, even if there were better compression algorithms, organizing the data as it's being processed in a "value,repetitions" structure could save a lot of memory. Again, depending if the data-set experiences high sequential repetitions.

_________________
SNES Tutorials (WLA DX)
SNES Memory Mapping Tutorial (Universal / LoROM) -- By Universal I introduce how memory mapping works, rather than just provide a LoROM map.
SNES Tracker (WIP) - Music/SFX composition tool / SPC Debugger


Top
 Profile  
 
PostPosted: Mon Mar 28, 2016 10:20 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 800
bazz wrote:
a "value,repetitions" pattern

RLE, basically. Exquisitely suited to this situation (even if an advanced method could do better). Yeah, I guess that makes that entire paragraph of mine look a bit silly...


Top
 Profile  
 
PostPosted: Mon Mar 28, 2016 10:53 pm 
Offline
User avatar

Joined: Fri Sep 02, 2011 8:34 pm
Posts: 476
So, in order to keep this thread well-focused on the new format as a whole and NOT just the streaming component, let's start talking about the overall format.

==== RIFF Chunk Format
I've been well-advised on #botb by blaze_pascal to incorporate a RIFF chunk format for easy parsing and modularity.

ie "you can regard chunks that you aren't interested in as black boxes"
'to get "past" a riff chunk you just need to read the header and then jump <length> bytes'

I've also been told to include version info for obvious reasons, and in the decoding code to "upscale" old versions to newer versions like so:
Code:
switch (version)
{
  case VERSION1: <convert version 1 to version 2>;
  case VERSION2: <convert version 2 to version 3>;
  case [...]
}

// notice there is no break statement.


I can agree with that.

I'd like to further document the different chunks briefly. Let me just summarize what I think a bare-bones necessity would be:
  • Dump Info (title, name, etc. -- fields similarly found in orig. SPC format) The "what-dumped-me" AKA emulator field would now be a string for aforementioned reasons. Also considering supporting Unicode, and unicode-16 at that, because I find it easiest / most well-supported.
  • SPC State (same fields as found in orig. SPC format)
  • Stream data (if present) - in RLE if applicable.

==== Regarding Stream "Export"

now regarding stream data -- let us briefly concern ourselves with the possibility that the "stream log" could contain non-brr-stream data (bad example: "change song" engine command) -- Or perhaps there are other commands being sent on non-brr-streaming songs that had never been recorded! This sounds like a rare but possible exception.

Because of this potential issue, my paranoia, perhaps credibly so - I believe the SPC Exporter should have a "stream-dumping" boolean. It's simply user-configurable -- IMO with a default of "always-off" -- I'm just afraid of seeing auxiliary data "streamed" that's misc. engine commands.. Although this could be at times desired to be streaming.

====

I hope y'all like what I'm cooking!

_________________
SNES Tutorials (WLA DX)
SNES Memory Mapping Tutorial (Universal / LoROM) -- By Universal I introduce how memory mapping works, rather than just provide a LoROM map.
SNES Tracker (WIP) - Music/SFX composition tool / SPC Debugger


Last edited by bazz on Tue Mar 29, 2016 9:08 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Mar 29, 2016 2:00 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7265
Location: Chexbres, VD, Switzerland
byuu wrote:
So here's the key to a much better format: when ripping the music track, log all the values read from $f4-f7 on the SMP to the end of the file. Remove the data for non-streaming tracks if you want (it'll compress down to nothing anyway), and leave it for streaming tracks. Timing of the accesses doesn't need to be logged, nor does the addresses. Just a linear stream of all bytes read, and then play back those accesses sequentially when playing the music. This can easily result in consistent playback because we have cycle-perfect timing of the SMP and DSP now. We ripped Tales' opening song in like 200KiB, whereas regular songs were the same ~68KiB of regular SPCs.

Very clever indeed! But how do you support infinite playback?


Top
 Profile  
 
PostPosted: Tue Mar 29, 2016 3:47 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
> It's funny you mentioned WLA-DX .. I even switched once to ca65 and then *went back* to WLA DX. I think I am masochistic these days, which could probably be why I'm good at any of this stuff.

You'd kind of have to be, yeah :P

In bass:
Code:
macro seek(offset) {
  origin {offset}&$3fffff  //hirom
//origin ({offset}&$7f0000) >> 1 | ({offset}&$7fff)  //lorom
  base {offset}
}
seek($c00000)


98% of mappings described in literally two lines of code in a macro. Yet you have the flexibility to implement vastly more complex mappers if you wanted (64MiB ROMs, MMC-based ROMs, etc.)

I will never understand (nor want to) the complexity of mapping in WLA-DX.

> Who is "we"?

The people on my forum that are heavily into SNES dev.

> Now I could get into further details of why I feel your better file format(s) or tool(s) did not gain popularity

You don't have to, I already know the reason.

> for Streaming -- Why is it safe to assume no timing info needs to be logged? Isn't that making an assumption that all data being written is at the earliest possible moment? The assumption might suit a lot of test cases, or all of them, but this is definitely an assumption! Unless you school me.

When you are emulating the SFM file, you're producing the timing and adressing information again. The bytes written to $f4-f7 that are logged act like an assembly line. It doesn't matter how fast or slow that line moves, so long as the bytes come out the other end in the same order, and they will as long as both the recorder and player have correct timing.

Emulator movie files work on the same principle: they are only a linear stream of 1 = pressed / 0 = clear bits recorded for each time the emulator polls input. So you can record a movie file that can be used to perfectly play back a video game with only 12-bits per frame, or 90-bytes a second, provided you have the original ROM for playback. SFM is the same, SFM is effectively the "original ROM for music playback."

> I don't see how the traditional SPC logging of this information doesn't already have this covered

SPC didn't know about the required state in the beginning. The existing rips are missing the information. Adding a new emulator-specific section to log new fields is not a solution. That's basically making another new format and calling it SPC still. You'll spend the rest of time trying to replace older SPC rips with better, newer ones; and trying to get people to use newer SPC players that support the new state.

> the minimum that SPC already provides seems sufficient and relieves us of additional complexity to the format.
> Can you agree with me to leave out emulator-specific state and just leave in traditional SPC state, namely DSP vals, CPU reg vals, and RAM snapshot.

It's not sufficient. It's not a full state capture. It may not cause any bugs in playback, but it might. It might not result in two different players producing different output (because they assume different values for the undefined state), but it might.

> Of course, even if I/we make a new format, SNES Tracker will support SPC as well!

Right, everyone will support SPC because that's the format that everything's already in.

And that's why everyone will keep using SPC.

And that's why iNES 1.0 will still be the predominant file format in 2116 for NES ROMs.

See? I told you I understood this :)

> I didn't know SNSF required a whole-system emulation.

It's basically the original SNES ROM. They just go in and hack out as much as humanly possible, and patch some of the code. So the reset vector jumps to the song player as soon as possible with a small patch. Then they kill out everything not used.

It's clever, but SFM is a much better way of doing it. Especially because it doesn't require someone with ROM hacking skills to create. And because you don't have to emulate the SNES CPU as well.

> I do wonder if it would take more or less space to log timestamped writes instead of bare reads

No matter the case, timestamps wouldn't save you at all. If the ripper and player don't have the same opcode timing, it will fall apart during playback. But again, it's a non-issue. We know the exact cycle timing of every instruction on the SMP and DSP, thanks to blargg. It has all been verified (although blargg's SMP core has errors, so you'd not want to use that.)

> Yeah, I planned that.

I was going to point out that it seemed a bit immature to associate your software with venereal diseases, but then it dawned on me that the C++ standard library's namespace is "std", so ...

> Of course, after a format is defined, someone like Byuu would be most fit for writing in the new SPC export feature, while someone like me could write the new SPC Import feature, and then we'd have a working prototype.

I gave up on it over the internal state serialization issue.

They say perfection is the enemy of good, but that's what got us iNES, IPS, SPC, etc in the first place.

I don't want to be the guy responsible for over-looking some detail that ends up requiring everyone to replace SFM with some newer, better format ten years down the line. Or much, much worse ... the format everyone says is "good enough" and just groans about the problem(s) it has.

> doing a "value,repetitions" pattern could be efficient. But compared to real compression solutions, this might be a joke.

Correct. The data will be very highly repetitive. Even in the case of ripping Tales' streaming opening song, compression helps immensely. Amateur hour compression like RLE won't hold a candle to even something as simple as ZIP.

And the biggest space savings in SNES music is that the sound player engine and samples are 95% identical between songs. This is why they use solid archivers like RAR for SPCs. It's better to just leave compression to better tools for the job. And when an even better compression comes along, you can switch to it without having to throw out your existing format.

> I hope y'all like what I'm cooking!

I don't mind you playing around with the idea. Maybe you'll come up with some new ideas I like :)

But I want to stress two things. First, my original warning: you will never gain any kind of serious adoption of your format, no matter how amazingly awesome it is. Second, I'm not planning to work on this now, so you would have to patch bsnes yourself to rip into your format, sorry. I am totally swamped with work as always.

> Very clever indeed! But how do you support infinite playback?

I've never seen a streaming game that has infinite playback.

Non-streaming games won't need it. Just like how infinite playback SPCs right now work, you'd return #$00 from reads from $f4-f7 once the stream log runs out (in this case, it wouldn't exist, so that'd be immediately.)

But even if we contrived some example of an infinite streaming song, it would eventually loop, so the format could encode its own "after X samples are decoded, seek back to sample Y" to form a perfect, clean loop just like MSU1 PCM files do.

The only way you could intentionally break this would be to create a truly irrational format (pardon the pun ... you'll see) by doing something like streaming the computed bits of pi on an endless loop. Which, I don't really care about silly cases that don't exist, and won't exist outside of intentionally trying to break the format :P


Top
 Profile  
 
PostPosted: Tue Mar 29, 2016 4:31 am 
Offline
User avatar

Joined: Sun Jul 01, 2012 6:44 am
Posts: 337
Location: Lion's den :3
byuu wrote:
SPC is complete and utter shit. But it was the first out the gate, and no amount of improvements will ever convince anyone to switch. See: IPS, CHT, SMC, ZIP, WLA-DX, etc.

The overall implication of this statement is simply not true. I know a lot of ROM hackers (myself included) who were early adopters of UPS/BPS, headerless ROM images, game folders etc. I admit those people may still be a minority to this day, but the numbers are clearly increasing.

As for the constant bashing of WLA DX, though I won't even bother defending it, I want to say that for my needs as a SNES developer, there's just no alternative at the current time. Also, if you don't like any of WLA DX's features and/or the current implementation of a given feature, head over here and file an issue, please. Constant bitching about it won't help improve the software, anyway. :wink:

_________________
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)


Top
 Profile  
 
PostPosted: Tue Mar 29, 2016 7:44 am 
Offline
User avatar

Joined: Fri Sep 02, 2011 8:34 pm
Posts: 476
byuu wrote:
Adding a new emulator-specific section to log new fields is not a solution.


Maybe not, but I'm not done assessing the situation.

This is undoubtedly less efficient than standardizing the new state fields -- BUT let's talk about if we didn't -- I can see a major emulator coming out with their own RIFF-chunk (optional) to convey their emulator-specific SPC state information. Any player's that don't recognize it can simply skip over it. That would leave us with "current-spc-playback" functionality or better playback for players that can recognize and import the emulator-specific data. And, since it's completely optional to include - if this turns out to be useless or not well-implemented, people can leave it out of the file anyways! That would still give us a better organized SPC file format.

Now this would be a BAD solution because that means any emulator needs to know about all these different-emulator-specific RIFF chunks if they want to gain the added state-info. Obviously, standardizing the fields would be the REAL solution -- but who's going to get all the SNES APU emulator developoopers together to conform on that level?



byuu wrote:
but we got bogged down because a true state capture has internal variables, and different emulators will want to name those fields differently (they definitely don't have official names.)


How many different major APU emulators in use are there? I expect the answer to be very small, and let's also talk about how many are cycle-accurate.

Could you imagine getting these developers to discuss together the kinds of additional state their emulators would use for a proper SPC save-state? It is possible we could identify similar components and then give them official names to include in a newer format.

But that sounds like so much work, while at the same time - all of these emulators seem to play regular SPC without the additional state just fine.

byuu wrote:
Some emulators won't even support certain state fields.


That's normal. No problem, no harm done.

byuu wrote:
others may require new ones not yet known for a perfect capture.


well if that happened, they wouldn't be able to play any regular SPC file either (or at least not perfectly), so no harm done. -- this new format would at least give them A CHANCE to play perfectly:

so you come up with a new version with the new field. if this "emulator-that-requires-new-field" is used to open a new-style SPC, it would simply be able to perfectly play the version that includes the new field, or play imperfectly (or not play) the older versions of the format (including current SPC format). Again, this is a BETTER compatibility situation than simply using the old SPC-format.


and yet, standardization in the SNES community?!?! haha -- yeah right. I mean, it's do-able. But not on my watch.

byuu wrote:
We know the exact cycle timing of every instruction on the SMP and DSP, thanks to blargg. It has all been verified (although blargg's SMP core has errors, so you'd not want to use that.)


Are the errors you talk about in Blargg's core documented? Can you provide reference to an error free core. The thing I like about Blargg's core is that it also has a "Fast" aka "good-for-slower-computers" implementation - I would hope a referenced core does as well.

The reason I want reference(s) is because I DO use Blargg's core in Snes Tracker currently, and it's doing great I have no complaints. I feel it's good enough. But it would nice to know where the next step forward might be in case I need to ditch this emulator for a better one. Ideally, SNES Tracker will have APU emulator abstraction anyways, so that drivers for different APU emulators can be made.

One of the concerns is that I require a lot of read/write access to a lot of emulator internals, and generally modifications to the emulator itself are required to generate the product I'm interested in. For instance, to Blargg's APU emulator, I added code to use libgme_M's new "report" facility to indicate all locations of read/write/execute/echo region/BRR reads -- that's how the memory window is generated. I'm not sure how best to "take in" new APU emulators and add these features as transparently as possible, so that I could keep up with version improvements potentially.

Then there's the fact that SNES Tracker (Debugger) may arbitrarily modify any RAM / DSP etc -- I seem to have been able to pull this off (lol) in a multi-threaded environment, but I'm not sure how that worked out.... I'm using SDL which is calling the APU emulator to produce new samples from an audio thread, and yet I'm somehow able to *I ASSUME, without error* modify freely!! At the very least, I am HAPPY with the results. lol <--> I am sure I spawned death in the eyes of certain engineers at my lack of attention to the cross-thread activity, but I'm HAPPY -- let's see how this pans out.

byuu wrote:
you will never gain any kind of serious adoption of your format, no matter how amazingly awesome it is.


I don't care if anyone adopts my format. Having created an answer to "SPC is crap" is enough for me.

byuu wrote:
you would have to patch bsnes yourself to rip into your format.


What is the minimum version of bsnes I can work with?? As you know, I have my fork that I'm curious I can use -- based off v073u1. I'd rather not use if the APU emu is outdated. https://github.com/bazzinotti/bsnes-classic

Having said that, I'm probably *NOT* going to implement stream dumping to an emulator, since that goes way-off-track for my main goal, creating SNES Tracker!! If some other people get involved, I'm more likely to help with a new format.

Yeah, I'm definitely not going to do it. If someone else were to do it, they could get in touch with me and we could put it all together - but my program *does* use Blargg's SMP core which Byuu already stated has errors -- meaning that if it's truly not fit for streaming (which honestly, it MIGHT still be) -- it would mean that I couldn't use STD to test the SPC's that stream anyways, until incorporating a more accurate SPC emu into it. And of course, I mean as a driver!!

EDIT:
byuu wrote:
> doing a "value,repetitions" pattern could be efficient. But compared to real compression solutions, this might be a joke.

Correct. The data will be very highly repetitive. Even in the case of ripping Tales' streaming opening song, compression helps immensely. Amateur hour compression like RLE won't hold a candle to even something as simple as ZIP.

And the biggest space savings in SNES music is that the sound player engine and samples are 95% identical between songs. This is why they use solid archivers like RAR for SPCs. It's better to just leave compression to better tools for the job. And when an even better compression comes along, you can switch to it without having to throw out your existing format.


I understand why "they" compress whole SPC archives -- but what are you suggesting for a single SPC file. You can't be suggesting to compress single files as zip as well? I'm thinking to use RLE for single files, and RAR for archives like they are already. Don't you agree?


Attachments:
File comment: SNES Tracker Debugger (STD) memory window
Screenshot_2016-03-29_10-29-17.png
Screenshot_2016-03-29_10-29-17.png [ 27.45 KiB | Viewed 2355 times ]

_________________
SNES Tutorials (WLA DX)
SNES Memory Mapping Tutorial (Universal / LoROM) -- By Universal I introduce how memory mapping works, rather than just provide a LoROM map.
SNES Tracker (WIP) - Music/SFX composition tool / SPC Debugger
Top
 Profile  
 
PostPosted: Tue Mar 29, 2016 11:28 am 
Offline
User avatar

Joined: Sun Jul 01, 2012 6:44 am
Posts: 337
Location: Lion's den :3
bazz wrote:
I don't care if anyone adopts my format. Having created an answer to "SPC is crap" is enough for me.

Good on you. :)

_________________
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)


Top
 Profile  
 
PostPosted: Tue Mar 29, 2016 11:46 am 
Offline

Joined: Mon Mar 27, 2006 5:23 pm
Posts: 1339
> I know a lot of ROM hackers (myself included) who were early adopters of UPS/BPS, headerless ROM images, game folders etc. I admit those people may still be a minority to this day, but the numbers are clearly increasing.

Not the ones I've seen. I won't name the person, but I even once had a person I helped out probably a half-dozen times with rather significant tasks say to me, "if you help me hack this next game, then I'll use BPS for the patch format instead of IPS!", which I found quite crass. Especially considering I've never asked that person for anything in return before.

I am hopeful that you're right though and that BPS picks up more steam. It's already five years old. RHDN still hosts beat v01 despite that being ancient. And see for example this from two months ago:
http://www.insanedifficulty.com/board/i ... xperience/

Quote:
All I'll say is that oftentimes when I see stuff like this, it amounts to little more than a sales pitch. It could be that BPS is indeed better, but the way I -- and a lot of people, really -- look at this is like so: Everyone uses IPS. No one has switched. IPS remains (to my knowledge) the most used patching method for mods right now. If there really is a better alternative, why isn't it used? Most likely because there isn't a problem with IPS, and until there is, any other "new" or "improved" patching methods are just about pointless.


Quote:
I've never had a problem with IPS. So i'm going to continue using it.


Quote:
I've used IPS and never had trouble with it. I won't be switching anytime soon. Begone, peasant.


And that's after repeated attempts to explain the benefits. People don't want better tools.

And then:

Quote:
So if you want to use a 6-letter name patch for Chrono Trigger on top of another ROM mod (translation or difficulty mod) then you can't do that if both patches are BPS-only.


Which is definitely wrong. You can stack BPS patches just like IPS, you just have to ignore the checksums when you do because it's not possible to store a checksum for a file in an unknown state.

> As for the constant bashing of WLA DX, though I won't even bother defending it, I want to say that for my needs as a SNES developer, there's just no alternative at the current time.

I've no interest in trying to convert people to a different assembler. Basically, nine out of every ten people who write large amounts of SNES ASM end up writing their own SNES assemblers anyway.

> Also, if you don't like any of WLA DX's features and/or the current implementation of a given feature, head over here and file an issue, please.

I wrote my own instead. I do that a lot. See: bsnes, BPS, SFM, etc ;)


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 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