Wow, it sure was a long time ago since I last was actively reading and posting here... 

Happy New Year to you, too!

Btw, you should use the full BASS. Not BASSMOD, as there's no .Net API for that.

This mean that i must download BASS.NET.API?

If you want to make things easier for yourself, then yes.

Make sure you don't have an older version of BASS.DLL in your "system32" directory.

ASX streams are quite easy to parse. Open an ASX file in Notepad and you'll see the address of the real stream.

In short, yes.

I'm sorry for replying this late once again, I've lacked time and resources to offer any support. Here's an update to try...

     http://www.un4seen.com/filez/2/xmp-mpc.dll

You could either memcpy() the data to "buffer" or let BASS_ChannelGetData decode the data directly to the STREAMPROC's "buffer" parameter. I'd suggest the latter. Also, why don't you use the "length" parameter instead of "sizeof(buf)"?

Procedure Proc(handle : DWORD; buffer: Pointer; length, user : DWORD);
begin
 bass_ChannelGetData(user, @buffer length);
end;

procedure TForm1.Button1Click(Sender: TObject);
var info : BASS_CHANNELINFO;
begin
 chan1 := Bass_StreamCreateFile(false, PChar(music), 0, 0, BASS_STREAM_DECODE);
 Bass_ChannelGetInfo(chan1, info);
 chan2 := BASS_StreamCreate(info.freq, info.chans, 0, @proc, chan1);
 if chan2 <> 0 then
   Bass_ChannelPlay(chan2, false);
end;

I've updated the memplay example with dynamic BASSMOD extraction/loading. It's not your only choice though, you can always use MemoryModule, compile it to a LIB file and link it with MASM.

I had tried setting mem to true before and it made no difference. Also, i think the free after init was a typo, i removed it a while back. My code has not changed other than to remove the free, but the music will still not play, even with mem set to true

*edit*

I have also noticed that even if you include bassmod.dll, the program will still require an external copy. Is there any way to compile it into the executable without packing it?

I've wrapped up an example using MASM for you to have a look at. You don't have to perform that memory allocation/copy stuff, you just use the pointer returned by LockResource.

Regarding including the DLL; I remember seeing some discussion about this - search the forum and I'm sure you'll find something.

You have to set "mem" (the first parameter) to TRUE which will let BASS know that the source is a memory location.

    invoke BASSMOD_MusicLoad, TRUE, ADDR pMusic, 0, 0, BASS_MUSIC_LOOP OR BASS_MUSIC_POSRESET OR BASS_MUSIC_RAMPS

Also, why are you calling BASSMOD_MusicFree just after BASSMOD_Init?

Try removing "vbNull" from BASS_Encode_Start and replace it with 0. vbNull is 1, and therefor, you're passing 1 in the "proc" parameter which could screw things up.

I also tried Ian's cd-contest and it encoded from a CD track to a FLAC file without problems. When I tried my own sample code in VB, it encoded, but no file was ever outputted. This is what I found out when using the FLAC "--H" option:

A single INPUTFILE may be - for stdin
stdin implies -c (write to stdout).

So, if using STDIN, FLAC will automatically output to STDOUT it seems (can anyone confirm this?). I wonder if Ian is using a ENCODEPROC to fetch the data and then manually write it to a file.

Edit: This sample code in VB works fine for me.

    Dim lngHandle As Long
    lngHandle = BASS_CD_StreamCreate(0, CLng(Text1.Text), BASS_STREAM_DECODE Or BASS_STREAM_AUTOFREE)
    If lngHandle = 0 Then
        MsgBox "Can't create stream: " & BASS_ErrorGetCode
        Exit Sub
    End If
    If BASS_Encode_Start(lngHandle, "flac -f -o bass.flac -", 0, 0, 0) = 0 Then
        MsgBox "Can't create encoder: " & BASS_ErrorGetCode
        Exit Sub
    End If
    Do
        Dim bytBuf() As Byte
        ReDim bytBuf(0 To 19999) As Byte
        BASS_ChannelGetData lngHandle, bytBuf(0), 20000
        If BASS_Encode_IsActive(lngHandle) = 0 Then
            MsgBox "Encoder died!"
            Exit Do
        End If
    Loop While BASS_ChannelIsActive(lngHandle) = BASS_ACTIVE_PLAYING
    BASS_Encode_Stop lngHandle

As you have had it going, would you mind sharing the actual syntax of the command line you asked Bass-Enc to send to flac.

This is the syntax he used;

flac -f -o bass.flac -

[Dragging the files or dir containing them to the main/mini panel to open them (and replace the playlist), something which I do 95% of the time since I don't use very big playlists, this causes all these bad files being added.]

Well, I did some more testing and yes, it is this plugin that occasionally (very often) still adds unplayable files like .png, .sfv and .txt. It's driving me completely bananas, to the point that I'm right now using the otherwise inferior in_mpc.dll.
A fix?

Thanks!

More info:

Here's another thing: When dragging the files (all the files in the dir) selected to the playlist, it works as it should. When dragging the dir containing the files to the playlist, same.

Dragging the files or dir containing them to the main/mini panel to open them (and replace the playlist), something which I do 95% of the time since I don't use very big playlists, this causes all these bad files being added.

Please? I really want to use the native MPC plugin but I can't since this is a showstopper bug. If not, could Ian please add an undocumented "never ever add these file types" INI setting (if you think it's outrageous to have such a setting in the GUI)? I've noticed the WMA plugin wants to add (and does play the audio part of) video WMV files too and I don't ever want to play those in XMPlay.

I'm sorry for the late reply, but I've been slightly busy with other things. I'll look into this ASAP.

I'd use a BASS_SYNC_END and create the stream for the next MP3 when the sync is triggered.

The value returned by BASS_StreamCreateFile shouldn't (although it can) be saved in a Variant variable. Use Long instead. Other than that, unless you want to entirely free the stream, call BASS_ChannelStop instead of BASS_StreamFree in your Stop_Click event handler. Regarding your issue, I can't see anything obvious that's causing your mono-output, so I guess it's something for Ian to dig into.

I would like to record (line in- microphone) the lowest quality mp3...or any format for that matter. Just need to keep the file size as small as possible. Can someone point me in the right direction?

Well, if you want to record and encode speech, I'd suggest Speex.

I know I can ask clever things  my next question about intervalls: what is the volume of interval of music in BASSMOD? As I tried to find out 0..100, I guess. Im I right?

AFAIK, yes.

It works fine for me. Put "bass.h" in your Include directory.

Also, did you include "windows.h"?

#include <windows.h>
#include <bass.h>
#include <vcl.h>
#pragma hdrstop
...

My code in the CallBack is:

Public Function RECORDPROC(ByVal handle As Long, ByVal buffer As Long, ByVal length As Long, ByVal user As Long) As Long

iLevel = LoWord(BASS_ChannelGetLevel(Chan)) 'check the record level

If bEncoderLoaded = True Then
            BASS_Encode_Write! handle, buffer, length
End If
End Function

TM.

I guess the exclamation mark after BASS_Encode_Write is a typo? Anyway, you're missing the "RECORDPROC = BASSTRUE" again. Without it, BASS won't continue recording. I've not tested the SafeCallback system, so I can't really tell - but I've used callbacks in VB before, and it's all went good. Also, you probably should use the "handle" parameter in the RECORDPROC (not the "Chan" global variable):

Public Function RECORDPROC(ByVal handle As Long, ByVal buffer As Long, ByVal length As Long, ByVal user As Long) As Long

iLevel = LoWord(BASS_ChannelGetLevel(handle)) 'check the record level

If bEncoderLoaded = True Then
            BASS_Encode_Write handle, buffer, length
End If

RECORDPROC = BASSTRUE

End Function

I've reuploaded my example application (same link as before).

Thanks for the time you spent here!

No worries.

Is that correct? ->
The good thing about the RecordProc is that is it being automatically fired when the buffer (lets say sound buffer of 5 ms) is full. And in the RecordProc we can check the level/ volume of the buffer. So this is why it's better than a timer which fires not often detect to e.g. detect a high level early enough to detect the first letter of a spoken word.
But when we check the volume in the RecordProc we can be sure that me are missing nothing! And we can even send that FIRST buffer (that has a high level) directly to the Encoding_Start, right? And this first buffer is not abandoned but directly send to the buffer. Because we do not say "Start the encoding now and record anything as soon as you are ready", but we say "Start the encoding with this buffer!".
Correct?

Yes. I'd call it "Initialize the encoding and write whenever threshold>=N" though.