| Author |
Message |
- Joined: 24 Jun 1999
- Posts: 1732
- Location: Paris, France
|
SSF format specification - draft
 Posted: Fri Jul 23, 1999 7:54 pm
|
Oh finally I think I'll say a bit on what I can propose.
Be sure to develop, it is only a preliminary idea.
The main loop would consist in a single byte:
bit 0: channel 1 frequency will change
bit 1: channel 2 frequency will change
bit 2: channel 3 frequency will change
bit 3: channel 4 (noise) frequency/option will change
bit 4: channel 1 volume will change
bit 5: channel 2 volume will change
bit 6: channel 3 volume will change
bit 7: channel 4 (noise) volume will change
Then after this byte, if it isn't zero, the appropriates values are added:
- 10 bits (padding to 2 bytes ?) for a frequency
- 4 bits (padding to 1 byte ?) for a volume
If the bitfield is 0, it is a special case and the next byte will contains the following informations:
bit 0->2: number of VBL to wait for (up to 8 VBL, which is already a long time for a song. In the rare
case where we have to wait a higher number of VBL, we'll simply repeat the same things.
bit 3: if cleared, wait for VBL (bits 0 to 2 are used), if set wait for a certain number of cycle: in this
case following to the current byte will be two bytes will a number of cycle. this isn't the most important
feature to implement, but that will allow voices to be supported in the format.
bit 4, 5, 6: unused yet. must be set to zero.
bit 7: end of song. not end of file. a file should contains an index of the songs at the beginning.
Defining the header is now trivial:
3 bytes: "SSF"
1 byte: 0
1 byte: version number
x bytes: information string. end by zero (so putting a zero directlry would be no information).
1 bytes: number of songs in the file.
8 bytes: reserved for future use. much be zero.
4 bytes * y: file pointer to each song
1 byte: 0
Then for each song:
4 bytes: "SONG"
3 bytes: song number in ascii. to allow easy hexidecimal ripping from the file ;)
1 byte: 0
x bytes: song title/information string. end by zero.
4 bytes: song length in frames. player will convert to minute/second if wanted
4 bytes: song length in byte <- not really needed. what do you think ?
1 byte: song type. 0 = PSG; in the future 1 will be FM. and maybe we'll discover another sound hardware for the SMS one day ;)
1 byte: number of VBL per second. should be 50 or 60. could be overidded or skipped by the software, of course.
2 byte: number of cycle per VBL. should be 228. <- hmm.. it is useful ?
8 bytes reserved for future use. must be zero.
|
| |
  
|
|
Nyef
|
Posted: Fri Jul 23, 1999 8:16 pm
|
Quote > Oh finally I think I'll say a bit on what I can propose.
> Be sure to develop, it is only a preliminary idea.
This wasn't exactly what I had in mind, since the NSF format that gave me the idea was ripped
NES code with a header (similar to the SID format, actually). This is workable, but I had hoped
to be able to take the music code from games like Zillion and Phantasy Star and just bash it up
a little in order to make it work. That way, if we interested some ROM hackers in the project, we
would have a ready-made song library in no time.
Quote > 3 bytes: "SSF"
> 1 byte: 0
This 0 byte should probably be 0x1a instead. Mainly for historical reasons (In DOS it's an EOF,
that's the real reason).
Quote > 1 byte: version number
> x bytes: information string. end by zero (so putting a zero directlry would be no information).
> 1 bytes: number of songs in the file.
> 8 bytes: reserved for future use. much be zero.
> 4 bytes * y: file pointer to each song
> 1 byte: 0
--Nyef
|
| |
|
- Joined: 24 Jun 1999
- Posts: 1732
- Location: Paris, France
|
Posted: Fri Jul 23, 1999 9:08 pm
|
Quote > This wasn't exactly what I had in mind, since the NSF format that gave me the idea was ripped
> NES code with a header (similar to the SID format, actually). This is workable, but I had hoped
> to be able to take the music code from games like Zillion and Phantasy Star and just bash it up
> a little in order to make it work.
It wouldn't be hard to add a feature in emulators to record musics to NSF files.
|
| |
|
|
Chris
|
Great Ideas
Posted: Fri Jul 23, 1999 9:48 pm
|
Also, if I write the SSF2MID each Vblank write is nothing more than a method used to waste time
inbetween notes? If so that is perfect! While my program is converting, if I come across a Vblank
byte or bit (I can't remember) just add 1/50 or 1/60 clock ticks to the timer (depending on the
Vblank version bit). I wrill pre-write out 3 Tracks each using #80 patch (square wave) and
I could probably get away with the sms noise channel by setting Track 4 to #120 or #121
(The breath and sea shore noise effects).
So far I like it. I like everything about the format.
Chris :o)
|
| |
|
|
Eric
|
Posted: Fri Jul 23, 1999 10:40 pm
|
Quote > If the bitfield is 0, it is a special case and the next byte will contains the following informations:
> bit 0->2: number of VBL to wait for (up to 8 VBL, which is already a long time for a song. In the rare
> case where we have to wait a higher number of VBL, we'll simply repeat the same things.
I'm not sure I understand this. 8 VBL (VBlanks?) is approximately 1/8 (NTSC) or 1/6 (PAL) of a second. In my opinion this is not a very long time. There will be many cases (especially in a song's bass-line) where the duration of a note will be much longer than 1/8 or 1/6 of a second. Shouldn't this field be larger? It could use bits 0-5. Bit 6 could be what you described as bit 3, and bit 7 would be the same.
Quote > The main loop would consist in a single byte:
> bit 0: channel 1 frequency will change
> bit 1: channel 2 frequency will change
> bit 2: channel 3 frequency will change
> bit 3: channel 4 (noise) frequency/option will change
> bit 4: channel 1 volume will change
> bit 5: channel 2 volume will change
> bit 6: channel 3 volume will change
> bit 7: channel 4 (noise) volume will change
> Then after this byte, if it isn't zero, the appropriates values are added:
> - 10 bits (padding to 2 bytes ?) for a frequency
> - 4 bits (padding to 1 byte ?) for a volume
This part is a little ambiguous in the case that more than 1 bit is set. Let me propose this addendum:
Immediately following the main byte the frequency/volume bytes will be arranged like this:
2 bytes (if bit 0 is set) channel 1 frequency
2 bytes (if bit 1 is set) channel 2 frequency
2 bytes (if bit 2 is set) channel 3 frequency
2 bytes(if bit 3 is set) channel 4 frequency
1 byte (if bit 4 is set) channel 1 volume
1 byte (if bit 5 is set) channel 2 volume
1 byte (if bit 6 is set) channel 3 volume
1 byte (if bit 7 is set) channel 4 volume
The main change is that rather than arranging the data as pairs of frequency/volume data, the data is grouped according to its function.
I believe this will be easier to implement if more than one channel's settings are changing during a cycle.
Also, this makes it easier to write the sound routines for using imported SSF data in someone's own program.
Eric
|
| |
|
- Joined: 24 Jun 1999
- Posts: 1732
- Location: Paris, France
|
Posted: Sat Jul 24, 1999 12:01 am
|
Quote > I'm not sure I understand this. 8 VBL (VBlanks?) is approximately 1/8 (NTSC) or 1/6 (PAL) of a second. In my opinion this is not a very long time. There will be many cases (especially in a song's bass-line) where the duration of a note will be much longer than 1/8 or 1/6 of a second. Shouldn't this field be larger?
In most games are channels frequency are rewrote on every frames. And sometimes the volume values, too.
Quote > It could use bits 0-5. Bit 6 could be what you described as bit 3, and bit 7 would be the same.
It's always safe to keep at least one unused bit.
[..]
Quote > > Then after this byte, if it isn't zero, the appropriates values are added:
> > - 10 bits (padding to 2 bytes ?) for a frequency
> > - 4 bits (padding to 1 byte ?) for a volume
> This part is a little ambiguous in the case that more than 1 bit is set. Let me propose this addendum:
> The main change is that rather than arranging the data as pairs of frequency/volume data, the data is grouped according to its function.
That's what I meant. Sorry if I wasn't clear.
|
| |
|
|
ziggy880
|
Posted: Sat Jul 24, 1999 2:02 am
|
Quote > > This wasn't exactly what I had in mind, since the NSF format that gave me the idea was ripped
> > NES code with a header (similar to the SID format, actually). This is workable, but I had hoped
> > to be able to take the music code from games like Zillion and Phantasy Star and just bash it up
> > a little in order to make it work.
> It wouldn't be hard to add a feature in emulators to record musics to NSF files.
That is true thatd itd be easily rippable but it isnt completely accurate personally I agree with nyef but
your format makes more sense for a data structure for a future music editor for the sms or for the people who cant work with the
code to find an init and play address though even I find it a little more difficult to find the sound routine
for the sms but Ive only looked at one game so far
|
| |
|
|
Nyef
|
Posted: Sat Jul 24, 1999 2:09 am
|
Quote > > > This wasn't exactly what I had in mind, since the NSF format that gave me the idea was ripped
> > > NES code with a header (similar to the SID format, actually). This is workable, but I had hoped
> > > to be able to take the music code from games like Zillion and Phantasy Star and just bash it up
> > > a little in order to make it work.
> > It wouldn't be hard to add a feature in emulators to record musics to NSF files.
> That is true thatd itd be easily rippable but it isnt completely accurate personally I agree with nyef but
> your format makes more sense for a data structure for a future music editor for the sms or for the people who cant work with the
> code to find an init and play address though even I find it a little more difficult to find the sound routine
> for the sms but Ive only looked at one game so far
What I was originally suggesting was that we do a "ripped" file format, and then we write a tracked music player in that format with source code for the game developers. That way, we get the best of both worlds.
--Nyef
|
| |
|
- Joined: 12 Jul 1999
- Posts: 891
|
If I understood it, I'd love it. Great idea! *nt*
Posted: Sat Jul 24, 1999 5:15 am
|
No Text!
|
| |
|
