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.

Messages - saga

Pages: [1] 2 3 ... 86
XMPlay / Re: 3.8 reports, queries and bugs
« on: 20 May '17 - 16:40 »
Attached is a very simple MOD... apparently too simple for the auto-normalization! ;D
Using pretty much normal MOD playback settings (with 50:50 pan sep), the playback is distorted on the left channel.

Not trying to be funny, but realistic:
Have you seen Rubberband being added to BASS_FX in the last 2.5 years? No, so most likely no work has been done.
Would it take a lot of time to integrate yourself? No, the Rubberband API is not complicated. Getting audio out of the BASS mixer and feeding it into the processing function of Rubberband (after a bit of API setup) and then putting it back into BASS won't be a lot of code to write, while you make it sound like it would be a terribly complex job. There is a full example (the Rubberband command-line tool) demonstrating large parts of the API. It may look like a lot of code at first but you can probably ignore most as you will most likely only use a fraction of the API.

Well, noone has apparently done it before, so you could be the one to implement it and then publish your results so that other people don't have to do it again. ;)

You could... just use Rubberband? It's not like it's impossible to use without an official BASS add-on.

MO3 / Re: Old UNMO3 IT header issues
« on: 5 May '17 - 16:56 »
Okay, I think with this information I can now build fairly reliable fingerprinting of IT files saved with UNMO3, and automatically fix IT files saved with UNMO3 older than ("stuff" update from January 2011). They are probably rare but they do exist here and there.

For anyone else trying to identify IT files saved with UNMO3, here's the fingerprint (feel free to correct if anything is wrong :)):
- cwtv and cmwt are both 0x0214
- row highlights are both 0
- pwd is 0
- reserved is 0
- MIDI pitch controller and MIDI config flags are never set
- edit history has a length of 0

The only applications I am aware of that are similar to this fingerprint are:
- CheeseTracker, but it always seems to write non-zero row highlights
- IT 2.14 without any patches, but it always writes a non-empty edit history (and is unlikely to write a reserved value of 0)

In addition to this fingerprint, for detecting old (broken) UNMO3 versions:
- If instrument mode is disabled but 4*smpNum zero bytes follow after the pattern parapointers, an UNMO3 version older than was used.
- If only the "message" extra bit is set and two zero bytes are read after the parapointers, an UNMO3 version older than was used.

MO3 / Re: Old UNMO3 IT header issues
« on: 5 May '17 - 14:18 »
Looking at various UNMO3-ed files, the difference does not seem to come from different UNMO3 version, but probably from different module settings.
Using UNMO3 2.4 from April 2008, I do not see those four extra bytes (i.e. only two zero bytes in front of the FX00 chunk) when converting codename_silver.mo3 to IT, but they are present when decoding the two MO3 files found in the attachment (the decoded IT files are also in the archive for convenience).

EDIT: I think I figured it out! Even in sample mode, UNMO3 2.4 from 2008 seems to reserve some space for instrument parapointers in the header (as many as there are samples). This is where the extra four zeros come from. It doesn't actually write out any instrument parapointers, so there are 4 * smpNum zero bytes after the pattern parapointers. Since Codename Silver is in instrument mode, I cannot see the extra bytes there.
Having written my own MO3 decoder I can somehow see where this is coming from (the MO3 file still contains instrument headers for each sample), but if you still have the source code for that old version, it would be good if you can confirm that this is indeed what UNMO3 was doing wrong.

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?

BASS / Re: ASIO device list
« on: 2 May '17 - 21:11 »
Audacity does not actually ship with an ASIO interface (it would violate its GPL license). This would mean that your user compiled Audacity by themselves. This is naturally something that only very few users do, so something seems fishy here. You should probably ask them if they are really 100% positive that they use an ASIO driver in Audacity or if it's actually a different driver they're using.

XMPlay / Re: adjusting playback speed of a MOD
« on: 30 Apr '17 - 20:22 »
The built-in module player cannot do this, but xmp-openmpt features four user-assignable shortcuts to increase and decrease the tempo and pitch of a module independently from each other, just like in the old ModPlug Player. To make the plugin play those module types that are normally handled by XMPlay, you have to add their file extensions to the "priority file types" list for that plugin (The full list would be: mod xm s3m it mtm umx mptm).

2017-04-23: xmp-openmpt version 0.2-beta23 released!

This is another small update which mostly brings some decoding improvements for a couple of formats:
- Add support for "WUZAMOD!" magic bytes in STM files and allow some slightly malformed STM files to load which were previously rejected (putup10.stm, putup11.stm) while tightening some other heuristics.
- Tighten heuristics for rejecting invalid SoundTracker files.
- Detect whether "hidden" patterns in the order list of SoundTracker modules should be taken into account or not. Fixes wolf1.mod, wolf3.mod and jean_baudlot_-_bad_dudes_vs_dragonninja-dragonf.mod.
- MO3: Clear MIDI macros for files that were originally saved with Impulse Tracker 1.0 and Scream Tracker prior to version 3.20.

See for further details.

xmp-openmpt for CPUs with SSE2 instruction set - that's pretty much any x86 CPU made in the last ten years. Any 64-bit CPU automatically supports this.
xmp-openmpt for old CPUs without SSE2 instruction set

xmp-openmpt website:

XMPlay / Re: XMPlay on windows 8.1
« on: 22 Apr '17 - 20:06 »
That's not quite correct, if a dependency is not met, a library will simply not load at all. However, the suggestion is still valid of course - any plugin could be causing the hang, so try removing them one by one until you found the culprit.

BASS / Re: BASS MP3 free missing frames
« on: 21 Apr '17 - 17:43 »
It's official now: MP3 licensing ends this weekend:

Thanks. It seems that font_modsize alone didn't work for some reason, but also setting font_mod did the trick.

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.

And if you don't want to write platform-dependent code for Windows, there are also platform-independent libraries similar to BASSMIDI, e.g. RtMidi. Unlike BASSMIDI, it doesn't synthesize the MIDI data on its own but sends it to any existing MIDI device.

Who owns the sysex buffer? Do you allocate it yourself? Maybe the fact that Ian's version works and your initial version doesn't is because the sysex buffer is provided by the system and gets reused between adding the event to the queue and removing it, leading to BASSMIDI only receiving garbage. To be safe, you should create a copy of the buffer after receiving it.

BASS / Re: System Mix - "extrasize" ?
« on: 3 Apr '17 - 16:52 »
ExtraSize is the size of the additional data in WAVEFORMATEX (compared to a regular WAVEFORMAT structure), minus the size of the ExtaSize field. All in all, its value should be 22.

XMPlay / Re: Skin visuals latency
« on: 3 Apr '17 - 11:53 »
That shouldn't happen. Do you see it with any visualizations, including the built-in ones, or just specific ones? It could be an issue with a specific visualization, but the built-in ones are all in sync with the music here.

BASS / Re: BASSXA: XAudio2 rendering for BASS
« on: 29 Mar '17 - 22:27 »
And what is the real benefit/advantage of using XAudio2?
And if it is really better and has significant advantages over Wasapi or DirectSound... shouldn't it be supported natively by BASS?
On Windows, XAudio2 is just a wrapper around DirectSound (XP) or WASAPI (Vista and later), so it's just yet another layer of abstraction. XAudio2 does not magically give you lower latency than WASAPI. It's only really interesting if you already have existing XAudio2 code that you would like to use with BASS.

XMPlay / Re: 3.8 reports, queries and bugs
« on: 27 Mar '17 - 17:56 »
The original files can be found here:
Test case 25 does indeed test volume vs effect column priority.

XMPlay / Re: 3.8 reports, queries and bugs
« on: 24 Mar '17 - 19:43 »
Thanks for the fix!
The "set volume" command in the volume column is "special" and always supposed to be processed first (also in IT), and since Scream Tracker has no other commands to which the IT special case would apply for, this fix is definitely wrong for S3M and only valid for IT. :)

BASS / Re: How to deal with one big flac audio file ?
« on: 22 Mar '17 - 23:44 »
When albums are ripped as one big file, there is usually a Cue Sheet going along with that file which contains the starting positions of all track. Don't try to be smart (e.g. by trying to deduce song ends by silence - this WILL go wrong), parse the cue sheet instead. This is how all common audio players do it. If there is no cue sheet available, it's the user's problem, not yours. :)

(Note that the cue sheet might also be embedded in the file as a tag, but I can't help you with the exact details like what the tag name would be for various formats.)

XMPlay / Re: 3.8 reports, queries and bugs
« on: 19 Mar '17 - 12:40 »
I think something is wrong with S3M "Fast Volume Slides". In the attached excerpt from Purple Motion's PANIC.S3M, the sound on row 6 should be about half as loud as the sound on row 8 (same later on row 14 / 16 and 22 / 24).

Great! ;D As a next step, a Strict-Transport-Security HTTP header should probably be transmitted to automatically redirect people who previously visited the HTTPS version of the site from HTTP to HTTPS whenver they click on a HTTP link.
If you do not want to enforce HTTPS for the entire site, I would at least strongly suggest to also adjust the forum links in the menu on the left side to point to the HTTPS version, no matter if the user is currently on HTTP or HTTPS.

MO3 / Re: Early variant of the MO3 format?
« on: 17 Mar '17 - 15:53 »
Turns out that the solution to the problem was even easier: :)

Pages: [1] 2 3 ... 86