Error message "Value must be positive and below the buffer height."

[Slamy]

Hello fstarred, I've compiled the lastest release 3.0.2.0 under linux the and xbuild process was successful. Then I did this:

mono ./Xrns2XModShell.exe resources/examples/test_global_commands.xrns --out=test --type=mod

This gives me the error message: Value must be positive and below the buffer height. Parameter name: top

Do you have some hints for me?

[fstarred]

This is an annoying error that seems to happen with mono (so on UNIX based system), I can tell you that while debugging program crashes even before xrns2xmod itself is called. If it happens, basically you should restart the console without resizing, then launch xrns2xmod with the command you like. Unfortunately I realized this is not the only issue, because with this error the tool is unusable and even worst mod conversion got weird sample conversion (do not know exactly why, but it's due of third part libraries).

So in a nutshell: If possible use the windows version :)

[Slamy]

Using Windows is not the best option for me. This console resizing bug can be fixed by avoiding certain Cursor operations. As the code is open source I'll try to investigate. I'm especially confused why samples inside XM files are ok and MOD files are not.

[fstarred]

You're welcome.

For the MOD issue, you can try "test_adjust_sample_frequency.xrns" inside examples folder. Don't forget to put a file called _test_adjust_samplefrequency.ini inside ini folder with the content:

[volume] [frequency] 0/0 = 11025

I've noticed MOD sample is completely out of tune...

[Slamy]

I finally got the time to actually test the program with my fixes as I now have the project ready I wanted to use it for. I don't know what you mean by saying that the MOD samples are out of tune. I've compared the tuning using Lingot (guitar tuning software) and while the original 44100 Hz sample was perfectly tuned, the ProTracker sample was only off by -20 cents which could be fixed using finetune. I also believe this only happens because the PAL base frequency is 8287 which is probably an Amiga problem. Also my guess is that 11025 is not a good frequency for ProTracker as the base frequency is 8363 Hz. As target samplerate this frequency could be doubled or halved and then I get no issue. Currently my ini looks like this:

[volume] [frequency] 0/0 = 16726 1/0 = 16726 2/0 = 16726 3/0 = 16726 4/0 = 16726 5/0 = 16726 6/0 = 16726 7/0 = 16726 8/0 = 16726 9/0 = 16726 10/0 = 16726

This makes the mod file a little bit bigger but as it won't be used in a game I can use higher samplerates in favor of sound quality.

[fstarred]

Hi Slamy,

First off thank you so much for your support, mostly because you solved the annoying bug of the console "Value must be positive and below the buffer height.".

About the tuning conversion: There are still some issues because:

1. I tried some basic samples, mod sound very out tuned (Unfortunately I have renoise on another pc so have very few spare time)
2. Forcing mod to 16 bit is very expensive for the MOD itself, because sample would be double sized and range of available tunes would be limitated. So said, if Linux has some issues with 8 bits sample (I don't know why), a possible solution would be to introduce a conditional before attaching the mixer, something like check the OS (it already does in other parts of code).

Once I can, I'll let you know more infos and I'll pull your request.

UPDATE Can you explain why the sample of the xrns file attached is heavier ( 2754 b ) if converted from develop than your branch ( 480 b) ?

In theory your branch force the 16 bit sample. I'm a bit confused now...

foo.zip

Greets Starred MediaSoft

[Slamy]

Hello fstarred,

I'm sorry that I added confusion about this 16 bit stuff. The forcing of samples to 16 bit was a workaround only for the BASS lib. It seems it has issues to generate 8 bit samples. This is why I just use BASS to resample it to the sample rate I want with 16 bit resolution and then remove the lower 8 bits inside GetModEncodedSample(...). This might be a strange workaround and rounding might be even better than just removing them but it works for now. I agree that OS detection might be a nicer step here. It's your project I only give hints and suggestions. :-) The fact that BASS has these issues is very confusing to me. But as this is a native library specifically compiled for linux this might be the breaking point. I think I will create a minimal project which just creates an 8 bit sample from a 16 bit sine wave which should be possible in a few lines. If this also does not work properly we should contact the developers of BASS. But maybe .... 16 bit results from BASS are also ok ^^'.

Now to your UPDATE: The sample size of elm_s_fmp_c4.wav is 2752 @ 48000 Hz. This explains the size of 2754 bytes when just converted as 8 bit without resampling.

I've made a change inside GetAllSamplesData(...) in ModConverter.cs which says that If no configuration is provided the original frequency is NOT used any more but replaced by 8363 Hz. I believe this is an important change as 48000 Hz is not a good sample rate to work with on a real Amiga as the DMA cannot reach that. If I calculate now I have 2752 samples * 8363 Hz / 48000 Hz = 479.48 bytes

I hope you understand why I needed to change that. The tuning options of ProTracker are primitive and limited from a fine tune of -8 to 7. Even transpose of samples is not supported. There is no other option than using doubles or halves of the base frequency if notes still need to be readable in ProTracker.

Greetings Slamy

[fstarred]

Thanks for your explanation, I forgot about your change. So my proposal as a default behaviour would be this:

Calculate the closest rate to the original that would fits with a multiplier of the base value of 8363 hz, in order to preserve sound as much as possible and don't mess with the tune. Especially for the first point, take an high sound like hi-hat and notice how the quality of the sound drastically drop down when lowering the sample rate.

So giving the above example, the closest rate of 48000 is 41815 hz (8363 5 - I'd discard higher values than original). Another example, for a 32000 hz sample, the converted value would be 25089 (8363 3).

Obviously all the logic about setting custom frequency would be kept as is.

Do you think this solution can work?

Greets SMS

[Slamy]

I agree that high pitch drums like hi-hats or even crashes get destroyed by a low sample rate. Looking for the highest possible and usable sample rate sounds like a very good idea. But not every rate is possible. The Amiga is a very strange device. Please look at this thread: http://www.pouet.net/topic.php?which=8628

As tranposing in the instruments is not possible, only a double of halve variant of the base frequency is usable. As your tool sometimes doesn't produce a perfect MOD file a manual editing process might be needed. At this point I don't want that the converter replaces notes by other notes. Replacing C-2 by C-3 for example is something that your tool already does. This is ok. But if C-2 is replaced by something like A-2 or so this would not be ok for most people. One exception might be a drum where I would highly encourage using this trick. Renoise is aware of sample rates of samples. ProTracker is not and directly connects note values with playback rates.

For example: C-2 is 8363 Hz C-3 is 16726 Hz

C-4 doesn't exist on ProTracker files that are conform to the standard. OpenMPT does support if the "Amiga Frequency Limits" checkbox is not enabled. Notes higher than that will not be played and printed as red in OpenMPT if enabled. So a higher sample rate than 16726 Hz does only make sense with drums were I don't care if C-3 is written on the Pattern or B-3 which is the highest available sample rate of 31677 Hz.

My suggestion here is that either 16726 or 8363 is used depending on the sample rate of the source file. If a sample rate is manually provided which does not fit both, a tranpose operation inside the Pattern data might be usable as this would be ideal for drums. Or does this already happen? I haven't tested it yet as I only tried doubles of the base frequency.

UPDATE:

I've just tried to use 22050 as target sample rate. I didn't knew that you are already changing the pattern data for correct playback. Even so I don't understand why you believe it's out of tune. Converting a tuned sample with 44100 is changed from note D# to G# and a fine tune is added by your tool. According to Lingot it's in tune! So it should work as expected right?

[fstarred]

Yes Xrns2xmod automatically adjust the note to fit the right the played, on first instance I was referring to the Linux bug until you find the trick :)

[Slamy]

Ok, I've prepared jet another commit I can push to you. But I don't know if this suits your design: How about this:

[volume] [frequency] 0/0 = High //This is an instrument 1/0 = High 2/0 = High 3/0 = High 4/0 = 26273 //This is a high quality drum 5/0 = High 6/0 = High 7/0 = High 8/0 = High 9/0 = 26273 10/0 = 26273 11/0 = High 12/0 = High 13/0 = 26273 14/0 = 26273 15/0 = 26273

"High" and "Low" are for 8363 (NTSC) or 16726 (NTSC) or their PAL counterparts. The problem with 16726 Hz is the memory usage and the limited bandwidth as you can't get very high with that base frequency as we are already at the limit. Having High and Low instead of numbers avoids using frequencies which depend on the systems clock rate. I've also changed the default from NTSC to PAL as I claim that more PAL Amiga users (and games) exist than NTSC. Even OpenMPT only works in PAL mode... which is why instruments had always about -20 cents in tune.

I'm pretty new to github and I don't know how to cooperate with you. A communication channel of some sort is missing. I'm feeling guilty for just pushing my stuff to your repo without asking even so you've invited me. I'm thanking you for your trust in my capabilities as developer.

[Slamy]

This issue is now obsolete and fixed on a feature branch. The next release will contain this new feature.