Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - saga

Pages: [1] 2 3
MO3 / Old UNMO3 IT header issues
« on: 5 May '17 - 00:29 »
This is kind of a follow-up to a thread from a few years back...

What I observed back then: UNMO3, at the time, wrote the number of edit history entries (which was 0, since it didn't write an actual edit history), even though the "embed edit history" special flag 0x02 was not set. The only data following the edit history are MIDI macros (Edit: and possible MPT extensions), so this is only relevant when the original file contained any non-standard macros or plugin stuff (which would then not be read correctly).

I no longer have this specific version of UNMO3, so I tried to reproduce this with an older version from April 2008, and - surprise! - that older version writes the "embed edit history" flag, and it writes 6 extra zero bytes before the MIDI macros! Given the low number of IT files that have non-standard MIDI macros, combined with the low number of IT files that have been uncompressed using UNMO3, I am not entirely sure if this would be worth a workaround, but it surely could be used for fingerprinting such files as UNMO3-made files.

So, now for the interesting part: When did this behaviour change from writing those extra bytes and the edit history flags to writing a few less extra bytes and not setting the history flag? Can you dig up an UNMO3 version from between 2008 and 2011 that would show the behaviour from my original post? Do you still have the old source code that could possibly explain why UNMO3 wrote those 6 (or 4, depending on how you look at it) extra bytes?

I know it is possible to partially override skin settings by placing the overriding skin configuration file next to the skin, but how would this be done with the default skin, is it possible at all?
The use case is that we use XMPlay's pattern vis at various demoparties for showing the pattern contents of modules in tracked music competitions, but with today's Full-HD projectors, the pattern vis font size tends to be a bit small. So I'm looking for an easy way of increasing the font size without having to look for alternative skins.

MO3 / Early variant of the MO3 format?
« on: 13 Mar '17 - 12:52 »
An OpenMPT user reported a problem with a specific MO3 file from a game (including download link to the file):;topicseen#msg44044
It seems to be an MO3 v0 file, but UNMO3/XMPlay cannot handle it. Using my own MO3 decoder, the first  thing I notice is that the decompressed length of the music data does not coincide with the claimed size (it's shorter). This might indicate that a slightly different compression scheme is used. Ignoring the decompression issue and assuming that the data was decompressed correctly, the next issue would be that the decompressed header looks mostly right, but not entirely. For example, num instruments is 0x6b0b and num samples is 0x0a65. Maybe it's supposed to be 0x0b instruments and 0x0a samples. Since I cannot think of anything else those 0x65 and 0x6b bytes would belong to, I think this confirms that the decompression was not done correctly.
So, long story short: Ian, do you recall if there was an early version of the MO3 encoder with a slightly different compression scheme? The user said the music plays as intended in the game, so I assume there must be some old BASS version that can handle this variant of MO3 v0, too.

« on: 10 Jan '17 - 01:07 »
If no loop points are specified in the SFZ file, SFZ players should use the loop points found in the sample files. I didn't test this with WAV files, but with FLAC files it definitely does not work. Both sforzando and OpenMPT support loop information in FLAC files by reading embedded WAV-style "smpl" chunks (stored as foreign metadata of type "riff"). BASSMIDI does not currently seem to support this.
Any information in the SFZ file may override information found in the sample files, so it is e.g. possible to change a normal loop found in a sample file into a sustain loop.

I have uploaded an SFZ+FLAC example file named to your FTP for testing purposes. In the example, loop points are stored in each FLAC sample, and the SFZ file changes the type of those loops into sustain loops.

General Discussion / HQ Dodo Dreaming
« on: 11 Mar '16 - 16:40 »
Hey Ian, the official Dodo Dreaming release is encoded at 112kbit - and while it sounds pretty good for this bitrate, I wonder if there's a higher-quality encoding available? ;D

MO3 / Strangely broken MP3 samples
« on: 9 Nov '15 - 01:58 »
It's been a while since I used MP3 samples in MO3, but I cannot recall having the following problems, so it might be sample-specific, or specific to this LAME version I use...

Consider the attached IT file with a bidi-looped sample. MO3 seems to unroll the bidi loop, but depending on the chosen quality level the loop length is incorrect, or the sample is completely detuned. For the reference, I'm using LAME 3.99.5 and the "LAME (VBR)" / "LAME" presets in MO3. Try encoding the example sample at some low bitrates and the problem should be obvious.

General Discussion / Forum slowness
« on: 9 Nov '15 - 01:05 »
I'm experiencing some really long page loading delays on this forum lately.
They occur at several physical locations (different ISPs), different computers and operating systems (some being linux systems with no virus scanners - so it's definitely not some scanner blocking the browser), no matter whether I'm logged into the forum or not.
In essence, when I load the forum page for the first time, it takes ten seconds or longer to load. Firefox' web developer console is not too helpful - It doesn't show any specific file that takes a long while to load. However, in general it seems that after loading the forum's index.php, the remaining files (e.g. background images) take a long while to be fetched. Interestingly the browser won't make any new connections during this time as well (probably hitting the maximum connection limit?). Is anyone else having the same issues?

MO3 / Minor conversion error
« on: 6 Nov '15 - 14:13 »
While playing around with writing my own UNMO3 implementation I have come across the following errors in UNMO3 and MO3:

1. The UNMO3 decoder does not seem to guard against out-of-range parameter values, in particular for the XM volume command. Let's say the original XM file has a volume command in the effect column with a parameter value larger than 40. When decoding the MO3 file back to XM, this value is written to the volume column, but its parameter is not validated, so as a consequence an entirely different effect is written to the volume column.

2. Also in XM, MO3 stores the panbrello command (Y) correctly, but UNMO3 converts it back to P (panning slide) instead.

3. Similarly, command Z in the S3M format is stored correctly in the MO3 file but UNMO3 converts it back to command S instead.

4. Volume-column panning in the S3M format is not converted correctly by MO3. It stores it as volume command (F 40 in the MO3 file).

5. Also, technically, UNMO3 should really write out a "beats per track" value in the MTM header of 64, not 0.

6. There also seems to be an issue with the MIDI channel setting, at least in IT instruments (not tested with XM yet): In IT, no MIDI channel = 0, first = 1, last = 16, mapped = 17. However, It seems that in the MO3 file both "no channel" and the first channel are encoded as 0, the second channel is 1, etc...

MO3 / MO3 header flags
« on: 6 Nov '15 - 00:26 »
Since the unofficial MO3 documentation is incomplete, I tried deciphering some of the header flags myself. However, some things are not quite clear yet. Here are my findings:

0x01: Linear Slides (IT, XM)
0x02 | 0x08: Is an S3M file
0x04: S3M fast slides
0x08: Is an MTM file, if 0x02 is not set
0x10: S3M Amiga Limits
0x20: unused?
0x40: unused?
0x80: Is a MOD file
0x100: Is an IT file
0x200: Instrument Mode
0x400: IT compatible Gxx
0x800: IT old FX
0x1000: unused?
0x2000: unused?
0x4000: unknown
0x8000: unused?
0x10000 | 0x200000: Extended filter range (why two flags)?
0x10000 | 0x100000: Has plugins (why two flags)?
0x20000: always set?

Also, the header seems to contain some kind of sample volume thing that is only used in IT and XM files, but I don't quite understand how this maps to IT's "sample volume".

Regarding sample flags - I guess values 0x02, 0x04, 0x08, 0x40, 0x80, 0x800 are unused?
Also, I noticed that the "compressed length" of a sample is either FFFFFFFF or 0 (depending on the codec) if it's a duplicate sample. But how do I know which sample it is duplicated from?

General Discussion / 2MIDI crashing on startup
« on: 7 Sep '15 - 00:55 »
I haven't tried it in a while, but I'm sure 2MIDI used to work under Windows 7. Now it just crashes right at startup, even with the updated version from 2010. Ian, can you reproduce this? Otherwise I'll just upload a memory dump.

MO3 / Changes in MO3 revision 5?
« on: 18 May '14 - 22:06 »
For some side project, I need to read out some data from MO3 files. Said project uses the "unofficial" reverse-engineered unmo3 code. I am aware that MO3 r5 added sample and instument filenames, which are stored as yet another zero-terminated string right after the sample / instrument name. However, this doesn't seem to be the only difference. After the names, 41 bytes of data follow in older format revisions. However, to prevent misalignment, I need to read two additional bytes in r5 files. Ian, can you shed some light on what those two extra bytes do?

Together with the release of libopenmpt, we introduce the new OpenMPT input plugin for XMPlay, xmp-openmpt. Completely with its own pattern visualisation, it adds a great number of supported module formats to XMPlay and can also be used to replace XMPlay's own module renderer if you wish.

xmp-openmpt adds support for over 20 new module formats to XMPlay, including MPTM, STM, ULT, 669, MED, FAR, MDL, AMS, AMF, DSM, OKT, DMF, PTM, PSM, PSM16, MT2, DBM, DIGI, IMF, J2B, GDM, PLM, PT36, SFX, MMS and can also be used to replace XMPlay's existing MOD, XM, S3M, IT, MTM, MO3 and UMX support.

xmp-openmpt download
report bugs

XMPlay / Default colours for plugin vis
« on: 6 Dec '13 - 00:46 »
Upon initialisation, a plugin vis gets a DWORD colors[3] parameter. Since I want to extend the xmp-openmpt pattern vis to use the same effect colours as those pre-configured in the skin, it would be nice to be able to access them. Are they actually sent to the vis, and if so, which index corresponds to which colour? If not, can you please add this? :)
Also, is there a way to use XMPlay's own pattern vis navigation keys in a plugin vis?

General Discussion / XMPlay in a bottle?
« on: 18 Jul '12 - 02:40 »
Quote from: irc://
<J> <-- Should this get a thread on the forums? :>

Yes it should! When can we expect to see XMPlay and BASS bottles on our shelves?

MO3 / MO3 trashes MIDI macros
« on: 11 Sep '11 - 19:03 »
Hi Ian,
I think there's a big problem with either MO3 or UNMO3 (I guess it's the former, but I really do hope it's not) concerning MIDI macros. If you read Impulse Tracker's MIDI.TXT carefully, you can see that MIDI macros can contain several variables, not only the "z" variable - those variables are (in lower-case) a,b,c,n,p,u,v,x,y,z. Compliant trackers / players should subsitute them by the appropriate content when parsing the macro. Upper-case letters A-F are constants.
What's the problem? Well, if you take a macro that has upper-case letters A-F (f.e. by simply taking the default resonance macros in the Z80-Z8F range), the resonance parameter (last two characters of the macro) are converted to lower case when converting the file back to IT with UNMO3. That is not correct. The default resonance macros have no variables in them, so they should be completely upper-case.
Now, when converting the attached IT file to MO3 and opening it with OpenMPT 1.19, it sounds OK, as OpenMPT 1.19 and older only handle the "z" variable and interpret all other characters als constants, but with the upcoming OpenMPT 1.20's new macro system (which can handle all variables, not just z), the resonance macros (in the Z80-ZFF range) are broken. If the letters are indeed stored as lower-case in the MO3 files, I'd suggest to cast them to upper-case in UNMO3.EXE/DLL, so that compliant applications can handle the macros correctly.

General Discussion / 1,000
« on: 9 Aug '11 - 02:46 »
So this is supposed to be my 1,000th post.
J suggest that it should be about bacon, so here's some bacon for you:

Apart from that, what can I say... Those four years went by pretty fast! :o

MO3 / note fades
« on: 25 Jul '11 - 23:56 »
it seems like IT note fades (i.e. "invalid" notes) are still not supported by MO3. I tried to encode an IT file, but after re-opening it, all note fades were lost. Can you pretty pleaaase fix the MO3 encoder so that it doesn't drop note fade commands anymore? This is really urgent...

XMPlay / Oblivious library?
« on: 24 Jul '11 - 12:52 »
Now this is something that hasn't happened to me in the past. Using XMPlay, I've noticed that many of my carefully tagged module files have vanished from the library, so as soon as I play them from the playlist, their previously correctly displayed playlist entry (with artist and song title) is replaced by the song title only. Checking the song properties also clearly reveals that the tunes are not in the library anymore. I've spotted this with several tunes from the same directory, but also single files. Sometimes it only affects some files from the same directory, not all.
The number of missing tunes seems to be quite high (maybe a few hundred), so this is quite a loss of tag information and unluckily there are also no shadow copies of the file that are old enough to recover from. Has the same happened to any of you?

BASS / BASS_INFO struct help looks broken
« on: 28 May '11 - 15:58 »
Hi Ian,
I think the table in the BASS help on BASS_INFO is kind of broken. I have IE9 installed, which I assume is being used for rendering HTML in the CHM viewer.

MO3 / unmo3 writes out malformed IT files
« on: 17 Jan '11 - 18:37 »
IT files generated by unmo3.exe/.dll can not load properly in trackers / players that read the edit history. While bit 1 (0x02) of the "special" flags is not set, it writes out two additional bytes before the MIDI config, which are only supposed to be there if an IT edit history is present. This effectively prevents the MIDI macros and plugin settings from being read correctly. Since many players and trackers rely on these two extra bytes without checking the "special" flag, the easiest solution would be set the flag and keep the two extra bytes there.

BASS / Outdated documentation
« on: 11 Sep '10 - 19:37 »
I just noticed that some parts of the documentation in the current BASS package are outdated. The pages on BASS_ATTRIB_MUSIC_VOL_CHAN an similar attributes have an example code like this:
Code: [Select]
int channels=0;
float dummy;
while (BASS_ChannelGetAttribute(music, BASS_ATTRIB_MUSIC_VOL_CHAN+channels, &dummy)!=-1)
Which will never terminate, because, as the BASS_ChannelGetAttribute documentation suggests, FALSE is returned on failure. So replacing "-1" with "FALSE" returns the correct number of channels/instruments/...

On the BASS_ChannelGetTags page, there's an example that shows how MOD sample names can be retrieved.
Code: [Select]
char *text;This gives an error, it should be
Code: [Select]
const char *text;

MO3 / Further optimization: Re-order samples
« on: 27 Jul '10 - 16:42 »
I've got an idea for further optimization in the mo3 encoder after having a look at an encoded file: I took an IT file in instrument mode, which had quite a few empty sample slots. To save even more bytes, those empty sample slots could simply be removed, so that the useless sample headers don't have to be stored.

BASS / Mod music and volume...
« on: 8 Apr '09 - 19:34 »
I have an .IT tune here (using no instruments, so no virtual channels) that's played at half volume (0.5). However, it sounds like it's terribly overamplified, so I wonder what can cause this? I have recorded a sample and uploaded it to your FTP ( has the .MO3 and the result in my program, recorded as .OGG)
I've enabled the Surround Mode 2 since it's a mono module, could this be the cause?

MO3 / Zxx Macros?
« on: 26 Mar '09 - 23:13 »
MO3 files obviously store macro configuration, as my highpass filter macros (configured in MPT) still work in an encoded file. However, when using unmo3, the macros seem to be gone and I get lowpass filters again. Is it possible that unmo3 simply "forgets" to write the macro container into IT files? If it is a bug, could you also fix it in the unmo3.dll please? :)

General Discussion / Breakpoint 2009
« on: 1 Feb '09 - 18:44 »
The Breakpoint 2009 website has just been launched. This year's Breakpoint has one problem, though: The main sponsors decided to not support the demoscene anymore! So there's no money. Next step: You, the sceners, have to save the party! By visiting Breakpoint 2009, you can make it happen! Who's coming?

- Me!

Pages: [1] 2 3