| Posted By
siz
on 2021-01-10
08:35:48
|  TED Music Collection
I always wanted a TED music collection where I can play music like I do with HVSC on a C64. Long time ago I've exchanged some e-mails with TLC and Gaia about the .C8M (Commodore 8-bit Music) format but they told me that it's not final. In the meantime HVTC was born but it lacks a very important (at least for me) feature: a generic container format which can describe the music and allows playing it back with a standard player. I've started working on a new format with Csabo and Gaia in the end of last year because we thought that the idea of a standalone player (you can load and run a music file and it plays itself) is great so we wanted a format which makes that possible but also defines standard file format which allows playing it back from a separate player.
Now that Luca mentioned that we don't have a format I think it's time to come out.
Be warned that I wanted to finish a generic standalone player routine at first but I still need time for that. Until then you can check out the format recommendation on my home page and some inside why do we need that.
Feedback is very much welcomed and in fact needed if we want to continue this.
My SizPlay has a preliminary version supporting this new format (including Exorcist - one of my favourites and the first part of Uncertain Future's music as examples) and I know that Gaia was working on TEDPlay support as well.
|
|
Posted By
gerliczer
on 2021-01-10
09:32:32
| Re: TED Music Collection
I have some questions and observations after a cursory glance:
- Is it really big endian as in MSB first LSB last?
- Marker would be better called signature, wouldn't it?
- Songflags may be complemented with a uses DIGIMUZ flag now.
- Durationblock would be better in player call counts instead of seconds. UI should do the math based on timing, timer1value and durationblock.
- I see initaddress and playaddress which are fine for generic music, however (at least) Csabo's V2 player has support for separate effect play calls. It can be worked around with special player calls but requires changing the "natural" state of the music.
- Does released have mandatory or at least recommended format? That could come handy for certain searches.
- How non-mandatory fields will be handled? In most cases I can't see easy ways to identify their absence.
- Was it intentional that quite a few fields are not aligned to 16 byte boundaries although they could be without much problem?
|
|
Posted By
Luca
on 2021-01-10
09:32:47
 | Re: TED Music Collection
The little but sweet Plus/4 scene never stops me to be surprised more and more  I would write pages and pages of text, taking in several parallel stories which characterised the past years, but no, I will keep my silent smile and social kindness as ever  Great project, wish the best for it!
Anyway, I would suggest to fix some text in that presentation, for example the HVSC doesn't take its name from a group, vice versa a HVSC group came *after* that the High Voltage project was launched, after several years. Again, the code only /HVTC folder had its role and several users had advantages in picking pure code from it, and now, poor folder, is gone forever to make HVTC more ductile; we should say: the new project has different aims, hence we don't need that :)
Btw, if an evolution of HVTC is coming, this sets me free to upgrade and fix it periodically, in the near future I can rest in the audience side finally and leave that to others. This incoming 21 files addon I was near to do can wait, there's no urge if everything will change, that's better for all of us ;) Pity that the TMC project has been unveiled only now, I could have saved useless time, because meanwhile I was waiting a sign from Gaia about the format to be defined and chosen...
Mad do you remember our chitchat we had some months ago? ;) Hug me tight, my friend
Allow me one little memory I have every time we talk about my HVTC project: the very first feedback it got has been "It's useless"
|
|
Posted By
Csabo
on 2021-01-10
10:34:41
| Re: TED Music Collection
"In the meantime HVTC was born but it lacks a very important (at least for me) feature: a generic container format which can describe the music and allows playing it back with a standard player."
Well, this isn't 100% correct, there were always 2 folders; one with run-able programs (/player) and the other exactly what you're saying (/HVTC). Though that format just never became anything. IMHO no-one used it... So much so that Luca decided we should just get rid of it very recently.
Putting the data into the run-able programs is basically a win-win; it's the best of both worlds. You guys can have your format, I can have ready-to-run PRG files
Also, something else I've been thinking about. Knaecke songs that are 2x (and a bunch of mine too) make the two calls at specific places (above and below border). If the generic player just calls them twice per frame, that will make the song sound different... at least a little bit. I guess people will have to listen to it and give their opinions if it's noticeable.
|
|
Posted By
gerliczer
on 2021-01-10
11:13:11
| Re: TED Music Collection
@Csabo: I wouldn't worry too much about 2x music peculiarities. What you describe means only about ±3ms jitter. I don't think most of us would be capable of noticing such minor difference.
|
|
Posted By
siz
on 2021-01-12
07:29:51
| Re: TED Music Collection
@gerliczer: Thanks for the feedback. My answers:
- Is it really big endian as in MSB first LSB last?
No, that's a typo, I'll fix it. I've planned to use the 6502 native byte order.
- Marker would be better called signature, wouldn't it?
I was thinking about that too but was unsure and went for marker. I'll rename it though.
- Songflags may be complemented with a uses DIGIMUZ flag now.
Yes, of course. I thought the same but wanted to do the update together with all the feedback.
- Durationblock would be better in player call counts instead of seconds. UI should do the math based on timing, timer1value and durationblock.
That was my initial thought too (although durationblock is a late addition). But storing player calls in 16 bit limits the duration of a 4x song to a bit above 5 minutes which might not be enough. And as this is planned to be an optional information only it does not have to be more precise than seconds. (and I don't want to do those divisions on the plus/4 )
- I see initaddress and playaddress which are fine for generic music, however (at least) Csabo's V2 player has support for separate effect play calls. It can be worked around with special player calls but requires changing the "natural" state of the music.
It was never an intention ot leave the player code intact. In order to encapsulate it in a container a lot of players should be altered. For example Exorcist player routine jumps $ce0e in the end so that has to be changed for sure. In HVSC the Defender of the Crown got a whole new playback timing logic (the original one used two separate timers for the song and the instruments) and it was rewritten to a single timer so it can be put in the PSID container.
So yes LODPlayerV2 needs a wrapper.
- Does released have mandatory or at least recommended format? That could come handy for certain searches.
I'll include it in the documentation. The recommended format is the same as for HVSC: "year publisher"
- How non-mandatory fields will be handled? In most cases I can't see easy ways to identify their absence.
There are not that many optional fields:
* timer1value: can be left to zero if not used
* text fields: should be filled with spaces (so in this case optional means it can be an empty string)
* durationblock offset and durationblock presence is marked in the fileflags
- Was it intentional that quite a few fields are not aligned to 16 byte boundaries although they could be without much problem?
Yes. I wanted to align the text fields to 16 byte boundaries so a monitor M1000 command will display them aligned to the beginning of lines. The rest are just put one after the other.
@Luca
I hoped that You will be glad that someone finally took the effort to define a format and You can be part of finalizing it.
I would have told you about this earlier but I started talking about a container format some 5-6 years ago and that one died away in about a month. In the beginning of December we were talking about our projects and I mentioned that I'd really like to see a TED music collection which can be played back comfortably on the real machine and the guys urged me to define a format. I wanted to give it a more presentable form before bringing it to the public but your comment in the SIDID topic signlled that it's the time now.
|
|
Posted By
gerliczer
on 2021-01-12
11:01:41
| Re: TED Music Collection
Hi siz,
Thanks for the clarifications. Meanwhile I managed to realize that my last question was a stupid thing to ask. I was a bit confused because I didn't read carefully that those offsets are file positions. And I had an "epiphany" regarding the optional fields. Presence of timer1value can be deduced from the content of timing. Free bits of fileflags could be used to signal presence or absence of the other optional fields.
PS: Either I don't know something very important or the recommended values to put in TED Timer #1 are a bit strange.
|
|
Posted By
Mad
on 2021-01-12
12:38:14
| Re: TED Music Collection
About 2x music and raster positions for the two calls (Knaecketracker). You definitely hear it if you place the two play calls at different raster distances (I had some tries on this already). I mean it's no problem, you can't say if it's wrong or right, but If the routines are played exactly like in Knaecketracker itself it would (sadly) be the best thing for replaying these tunes (I think)..
Remember there are guys (Audiophiles) who say they can hear if your electric audio wiring is shilded with gold.. Even if that is bogus, there are people who can distinguish a lot if it comes to sound.. But it's 100% your choice, no one would notice it except perhaps the musicians itself.
Btw: Degauss uses a format like
raster1:
jsr tick
jsr output
raster2:
jsr output
for double speed tunes. Same for quad and so on speed tunes.. There is a tick function (per frame) and an output function..
|
|
Posted By
Hermit
on 2023-02-11
09:05:50
| Re: TED Music Collection
Hello Plus4 Sceners. I'm Hermit, just got a kind registration by Luca. I've read through all the TMF/C8M/whatever fileformat related proposals/implementations and the source-codes of Siz and Gaia & TLC. Both C8M and TMF are likeable, but for now Siz's latest TMF seems the most supported format. I have a further idea (already emailed to the people involved) that could make the format even more compatible with Luca's existing runnables in 'HVTC-player' folder: put the TMF-format header with metadata at the end of the PRG-file instead and point to the header by the BASIC line-number which is otherwise not a very informative unused field. This way all PRGs in HVTC could be executed by Plus4/emulator as before, and the appended TMF header could contain further information about the tune. I'd like to give a .ted or .ted.prg extension to these files (as an analogy to .sid), if that's not too occupied already for some Plus4 file-format, to distinguish them from plain prg files, though the MagicID/signature at the header's start would still be able to do that. There should be a field in the TMF-header (or PlayerAddress==0) that would indicate if the playback should rely on the original player-code and require a full Plus4 environment/emulation (like RSID) instead of PSID-like playback. I'll provide an export to this TED(TMF) format in TEDzakker and hopefully the players will support these formats, or maybe I'll make a player too. But most importantly, there must be a conversion/extension of most (if not all) HVTC .prg tunes into the format to be playable by players. I'll try to automate that task as much as possible, Siz's TMF tool is already a step towards this goal. Author+title names could be taken from HVTC-foldernames/filenames for the time being. On the other hand Luca must have a high amount of information about the entry-points and playback-models of the tunes in HVTC, those could be added to the headers. And the playtimes/durations of the different tunes (supported by Siz's new TMF-format) would be a nice addition, something that I have always missed in .SID formats. I hope we can bring this topic forward now as so many good-sounding and contentful TED tunes are being composed nowadays...
|
|
Posted By
Murphy
on 2023-02-13
14:34:50
| Re: TED Music Collection
It will be a great step if TEDzakker can save to TMF.
|
|
Posted By
Hermit
on 2023-02-14
06:32:47
| Re: TED Music Collection
About the multispeed-playback: The way how SID tunes handle special multispeed schemes is simply letting the custom native playback code handle them. For example when I export a multispeed tune from SID-Wizard I use the wrapper init and play-calls that call the real init/play in turn, but first they perform the counting to determine which of the player-routines to call. So it's highly configurable when 'tick' or 'output'/'update' player-calls are performed. No need to complicate the TMF format with all these schemes IMO.
@Murphy: of course the next TEDzakker-release will export TMF-format. And I'm working on a player and keep contact with Siz meanwhile about possibly required enhancements of TMF for HVTC. Plus4-scene, stay tuned...
|
|
Posted By
Luca
on 2023-02-14
10:12:58
| Re: TED Music Collection
The best and better desirable case of multispeed playback is the classic rastertime-equidistant PAL one, in which the callbacks are symmetrically placed: 156 scanlines for 2x, 104 for 3x, 78 for 4x and so on.
The alternative case is the one in which the coder did not place a symmetrical time per frame.
A third case includes various sub-cases of variable time between the callbacks, mostly due to a not stable code: a 2x tune may have a 50/50 different callback scanline, or a much complex cycle of different values, as closer as they are to the original behavior of that code, and usually I build up a table of values to be read at every frame in order to make it sound similar.
Similar cases can be found in the single speed players too, some tunes are slowed down by a machine's IRQ not shut down, some play with an average speed between all the different values of $FF0B read by the code frame by frame... Anyway those are all exceptions, and even in the multispeed sounds there's a common good usage of the rastercounting. They exist btw, and a comprehensive format shoud keep them in count too. The worst of all are the ones from Misfit, who uses to code some resulting sound from different parts of some horrible spaghetti-code, often deviated by the effects at that moment on the screen
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
