Well, it was bound to happen some time. Now being posted at Roberto's site (http://www.inf.ufpr.br/~rja00/ ) is Beta0.1 version of 'lameENCdrop'.

This is lame with a GUI. It is NOT a frontend to the CLI. CDex users will find the encoding options interface rather familiar but, otherwise, it is very similar to the oggdropXP interface. It uses LibSndFile for input and generates bit identical output compared to lame.exe (both being my own ICL compiles).

While I am reasonably confident there are no obvious bugs, if you find any, please advise soonest!

Enjoy!

john33

it looks great, john...

no bugs to report, but a few "requests"

#1 perhaps a "custom" commandline option
#2 in encoding options, perhaps the ability to also select the grayed out options? but in a way that this option can be turned off and on, and be obvious to the newbie...

or not...

later
mike

Very cool john33!

Lot's of people have been waiting for something like this I think (a totally integrated drop solution). Have you announced this on the lame-dev list? I'm sure quite a few of them would be interested.

And just a quick thought.... have you ever looked into using something like qt or gtk+ for the gui? It would be even cooler IMO to have a cross-platform LAME gui.

Anyway, keep up the good work!

Hi Dibrom

Thanks for the thoughts. I'll look into it.

john33

Ok, just to make it clear. The LameEncDrop 0.1b uses the latest LAME 3.92a Build so it won't be bit to bit compatible with LAME 3.91 Build.

So what new features does the 3.92a build have?

Cheers
AgentMil

Hmm, if this is the case, in my opinion it's not good to use alpha build here. Too many times these alfa builds have had something broken, or something that previously worked well, works unoptimally.
Alpha builds are just development builds which shouldn't be used here.

Its in the LAME tag of my files. LAME 3.92a is in them.

If you don't like the alpha build, I can always make a compile of the stable version.

john33

Well, have you tested that the alpha build you used works correctly in all the same situations as 3.91 stable?
I just think that no Lame dev would recommend the use of alpha build here...
Can you guarantee that it works the same or better than 3.91?

Well, during beta testings, I encoded lots of different files (Wav, ADPCM, AIFF, SND) to lots of differents bitrates and presets, and everything worked fine.

But, of course, I didn't use every possible configuration - lame would be version 4.0 when I finished that.

Seems pretty stable to me. And is better than Lame.exe regarding libsndfile implementation.
(Lame never recognized correctly my IMA files... )

Regards;

Roberto.

Since the first version of LameEncDrop seems pretty stable (I can't see any bugs or problems with the code) I would recommend that john33 compile a *FINAL* version using the LAME 3.91 stable source, and then continue work on the program using the LAME 3.92 alpha sources. This way we can have a stable program and a bleeding edge edition. This way we can cater for those for want the stable version and a version that will not scare newbies away from using LAME, and the other for the people who want to use the newer alpha version for development and testing.

One final note, is it possible to change the logo to the P4 one? Cause the one in there looks pretty dated and the P4 one looks so 1337 .

Cheers
AgentMil

Humm... I always wondered if that logo won't bring problems from Intel. They probably have TMs on that thing.

Maybe someone could come up with a trademark-free logo for lame?

Regards;

Roberto.

True rjamorim, it might bring legal issues, but since LAME is free I wouldn't think that would be a problem, as most companies pursue legal action if the program is trading on the trademark (e.g. using the trademark to make profit). Since LAME and LameEncDrop does not get sold I don't see a problem (is there any legal people on this board that could clear that up?).

Yeah but rjamorim right, we could also do with a completely new LAME logo completely modern and sleek and original.

Cheers
AgentMil

Following AgentMil's comments, and since no one has reported any problems, lameENCdrop has been renamed as Version 1.0.

Two new versions, plus sources, have been uploaded to Roberto's site, so should be available a little later.

One version is compiled with LAME3.91 and the other with 3.92alpha. The 'About' box indicates which library version you are using. Both versions also now display the P4 style logo which rotates during encoding, rather than the lurid 'light show' that was there before!

Hopefully, Roberto will have room for both versions but, if not, we may have to find another 'home' for one of them!

john33

Cheers john33! That light show was pretty yuck, but at least we had a LameEncDrop first version with no bugs (hopefully for everyone, I tested mostly the commonly used switches and played around with others and no problems). Can't wait to see the new one!

Cheers
AgentMil

Hi John,

I was wondering if you have any plans to make a similar type program like the oggropxp frontend but for Musepack?
They are both emtremely cool, BTW :-)

Hi all. I started thinking about trademark-free LAME logos a while back when I saw the question posted in another thread. Give me another week or two and I might finish some new ones to suggest here, for possible feedback/input. (And yes, if I design a logo for this purpose then the community could safely and freely use it as long as no one is trying to sell the image, etcetera.)

john33, I had another thought on the spinning graphic implementation: How difficult would it be to configure the utility to use Winamp/Sonique visualization plugins? The SDKs for each are available, but I don't know how difficult the implementation would be.

-M.

I'm not John, but I think that I can answer this one.

The problem here is that the encoding sources are not available. So, all that can be done is a drag'n'drop decoder - which already exists, by the way: MuseDecDrop, by Layer3Maniac. (Available at my site)

Regards;

Roberto.

Edit: New files already available.

Yep, Roberto is absolutely correct. Without access to the MusePack source, I cannot give you what you would like. Layer3's 'drop' frontend is as good as it will get unless the source is released, which seems unlikely, BTW.

Regarding the Winamp,etc., visualisations, I don't know without researching it!! Currently, I'm just using small BMPs as frames.

john33

Thanks Roberto and John.

Sorry, it never occured to me that the source would be required for that... pity tho, those little extra touches you have made like the progress bar etc. are appreciated.

Regards
Jeff

ummmm... i'm probably missing something obvious here and going to appear foolish and regret asking this but here goes. I was under the impression that 3.91 stable and dibroms 3.90.2 compile were the same, and I just checked the thread on latest recommended compile and it confirmed that. I havent been following lame developments lately so have still been using 3.90.2 for mp3's.

Well I just encoded a song with LameEncDrop (3.91) and also with dibroms 3.90.2 icl compile (--alt-preset standard). The one encoded with LameEncDrop is 207kbps and dibroms compile is 214kbps. That seems like a big size difference and I was wondering why? More importantly, is there a difference in quality?


P.S. another file 3.91 was 180kbps and 3.90.2 was 186kbps

I can't remember off the top of my head, but I think that Dibrom's compile switches are slightly different to mine, and the effect is on the bitrate. I believe numbers of people raised the same question when the ICL compiles first appeared and I think the general consensus was that if there was an audible difference, it was beyond the capability of our ears to discern!!

I would suggest that if it sounds the same to you, any other qualitative judgement is irrelevant.

john33

Feel free to correct me if I'm wrong, but my understanding is that this will ONLY affect encoding when the encoder is switching bitrates on the fly; for CBR encoding, both 3.90.2 and 3.91 should ALWAYS produce identical results, regardless of whose compile is used. Correct?

This would mean that Dibrom's ICL compile is just ever-so-slightly better at recognizing how much compression a sample can stand, without degradation. Sort of like the Monkey's Audio "neural coding," or somesuch... those switches affect how much intelligent imagination the program uses.

... and as for the switches Dibrom used in his ICL compile, I scouted through the list as well and couldn't find any proper explanation of them. Of course, I may just not have dug deep enough. Dibrom, would you be willing to explain/document your ICL modifications so that others could continue your "Dibrom-optimized" compiles (or point us back to the right thread if you've already done so)? We all realize the perils of a busy schedule, but I'm sure there would be others (Roberto? I notice you've begun hosting ICL compiles...) willing to maintain your work in this area.

- M.

Well, just to make it a bit more interesting, I just did some testing using the lame 3.91 libs as the base.

I created an ICL optimised compile; a MSVC standard compile, both of lameENCdrop; and a MSVC standard compile of lame.exe. Just to repeat, these were all lame 3.91.

I used three different files all encoded with a variety of alt presets and even with r3mix(!!!) and they were all bit identical as between the different compiles.

Now in view of what has been said before about all this, would someone like to explain this please?

john33:confused:

Different compiles with different compiler switches will sometimes cause LAME to produce different ouput. There is no code in my 3.90.2 compiles which causes any difference.. nothing like "neural coding" or whatever.

As for the switches I used, I would be more than willing to give them out, but it's a matter of practicality for me at the moment. I'm getting ready to move again which means most of my stuff is packed up. I don't have access to most of my archives, which includes the 3.90.2 stuff. I do have the 3.90.2 zip file on a laptop which isn't packed up but the laptop has no floppy drive or cd-r, and I don't have a network connection to hook it up to... so getting the .zip file off there is going to be a pain in the ass.. heh.

At any rate.. all that is needed is the 3.90.2 distribution .zip file. It contains the makefile I used and the all the necessary instructions to duplicate the compile. If anyone has this easily available, then speak up please

Someplace I know I've archived the original distribution for 3.90.2, but until I can find it again here are the necessary files themselves: Dibrom's "Makefile.MSVC" and "Compile_Info.txt". I tried to compress these into a small *.zip file so they could be attached here, but I kept getting a message about trying to attach an invalid file type... so I'll just cheat with a cut-and-past job at the end of this message. Thanks for reminding us that we'd already seen them, Dibrom. I guess like most folks, I didn't think about what those "Compile_Info" notes were. Silly me!

Thanks also for correcting me on that "neural coding or whatever" analogy. I knew that wasn't really what was going on, but it was the closest comparison I could think of on-the-fly... hope I didn't confuse anyone with it.

- M.


**(Compile_Info.txt)***
This .exe was compiled with ICL 4.5 with the following options in a 3 step process:

1. "nmake -f Makefile.MSVC PROF_OPT=GEN OPT=ULTRA"
2. The created file was then run through some common functions such as encoding and decoding to generate a profile.
3. "nmake -f Makefile.MSVC PROF_OPT=USE OPT=ULTRA"

This creates an .exe which uses profile guided optimization, which seems to allow a slight speed increase (2%-5%).

This .exe should be as fast or perhaps slightly faster than Mitiok's "fast" compiles.
*****(end of file)*****


****(Makefile.MSVC)****
# Makefile.MSVC: MSVC Makefile for LAME 3.88
#
# 2000-11-21 Robert Hegemann e-mail:
# dedicated to the LAME project http://www.mp3dev.org
###############################################################################



#__ readme ____________________________________________________________________
# nmake -f Makefile.MSVC
# -> build lame and dll, but not mp3x
# -> use Robert's code modifications
# -> assume INTEL compiler available
# -> assume NASM available
# -> assemble MMX code with NASM
# -> optimize for PIII
# -> single file optimizations
# -> no compiler warnings
#
# passing arguments, one can modify the default behaviour:
# COMP=<not INTEL or BCC> -> use MS compiler
# WARN=<anything but OFF> -> give verbose compiler warnings
# VERBOSE_VEC=<anything but OFF> -> give verbose vectorization information for Intel Compiler
# PROF_OPT=<GEN,USE> -> generate or use profile guided optimzations for Intel Compiler
# OPT=<NORMAL,EXTRA,ULTRA> -> different Intel optimizations
# ASM=<anything but YES> -> no NASM nor MMX
# MMX=<anything but YES> -> do not assemble MMX code
# CFG=<anything but RH> -> disable Robert's modifications
# OGG=<anything> -> have Vorbis library, use it
# CPU=P1 -> optimize for Pentium instead of P II/III
# GTK=YES -> have GTK, adds mp3x to default targets
#
# Example:
# nmake -f Makefile.MSVC CPU=P1 GTK=YES
#____________________________________________________________________ readme __



# targets <-> DOS filenames
T_LAME = lame.exe
T_LDLL = lame_enc.dll
T_MP3X = mp3x.exe

# default targets
PGM = $(T_LDLL) $(T_LAME)

# some default settings

! IF "$(COMP)" == ""
COMP = INTEL
! ENDIF

! IF "$(ASM)" == ""
ASM = YES
! ENDIF

! IF "$(MMX)" == ""
MMX = YES
! ENDIF

! IF "$(CFG)" == "NO-ALTERNATE-CODE-AVAILABLE"
CFG = RH
! ENDIF

! IF "$(CPU)" == ""
CPU = P3
! ENDIF

! IF "$(OPT)" == ""
OPT = NORMAL
! ENDIF

! IF "$(WARN)" == ""
WARN = OFF
! ENDIF

! IF "$(VERBOSE_VEC)" == ""
VEC = OFF
! ENDIF

! IF "$(PROF_OPT)" == ""
PROF_OPT = OFF
! ENDIF



OFF = win32

! MESSAGE ----------------------------------------------------------------------
! MESSAGE building LAME featuring $(CFG)
! IF "$(ASM)" == "YES"
! MESSAGE + ASM
! IF "$(MMX)" == "YES"
! MESSAGE + MMX
! ENDIF
! ENDIF
! IF "$(GTK)" == "YES"
! MESSAGE + GTK
! ENDIF
! IF "$(OGG)" != ""
! MESSAGE + Ogg-Vorbis
! ENDIF
! IF "$(COMP)" == "INTEL"
! MESSAGE using INTEL COMPILER
! IF "$(PROF_OPT)" == "GEN"
! MESSAGE + compiling profile generating binary
! ENDIF
! IF "$(PROF_OPT)" == "USE"
! MESSAGE + compiling binary using pre-generated profile
! ENDIF
! IF "$(OPT)" == "NORMAL"
! MESSAGE + perform single-file optimizations
! ENDIF
! IF "$(OPT)" == "EXTRA"
! MESSAGE + perform multi-file optimizations
! ENDIF
! IF "$(OPT)" == "ULTRA"
! MESSAGE + perform multi-file optimizations over entire program
! ENDIF
! ELSE
! MESSAGE using MS COMPILER
! ENDIF
! IF "$(CPU)" == "P1"
! MESSAGE + optimizing for Pentium (MMX) (may slow down PIII a few percent)
! ELSE
! MESSAGE + optimizing for Pentium II/III (slows down Pentium a few percent)
! ENDIF
! MESSAGE ----------------------------------------------------------------------



! IF "$(COMP)" != "INTEL"
! IF "$(COMP)" != "BCC"

#__ Microsoft C options _______________________________________________________
#
# /O2 maximize speed
# /Ob<n> inline expansion
# /Og enable global optimizations
# /Oi enable intrinsic functions
# /Ot favor code speed
# /Oy enable frame pointer omission
# /G5 Pentium optimization
# /G6 Pentium II/III optimization
# /GA optimize for Windows Application
# /GF enable read-only string pooling
# /Gf enable string spooling
# /Gs disable stack checking calls
# /Gy separate functions for linker
# /QIfdiv generate code for Pentium FDIV fix
# /QI0f generate code for Pentium 0x0f erratum fix
#
# remarks:
# - aliasing options seem to break code
# - try to get the Intel compiler demonstration code!
# ICL produces faster code.

# debugging options
# CC_OPTS = /nologo /Zi /Ge /GZ
# LN_OPTS = /nologo /debug:full /debugtype:cv /fixed:no

# profiling options
# CC_OPTS = /nologo /Zi /O2b2gity /G6As /DNDEBUG
# LN_OPTS = /nologo /debug:full /debugtype:cv /fixed:no /profile

# release options
CC_OPTS = /nologo /DNDEBUG /O2 /Ob2 /GAy /Gs1024 /QIfdiv /QI0f /YX
LN_OPTS = /nologo /DNDEBUG

! IF "$(CPU)" == "P1"
CC_OPTS = $(CC_OPTS) /G5
! ELSE
CC_OPTS = $(CC_OPTS) /GX
! ENDIF

! IF "$(WARN)" == "OFF"
CC_OPTS = $(CC_OPTS) /w
! ELSE
CC_OPTS = $(CC_OPTS) /W2 /Wport
! ENDIF

LN_DLL = /LD
LN_OUT = /Fe
CC_OUT = /Fo

CC = cl
LN = cl
#_______________________________________________________ Microsoft C options __


! ELSE

#__ Borland BCC options _______________________________________________________
#
# first draft, DLL not working, generates very slow code!
BCCINST = C:/Borland/BCC55

CC_OPTS = -pc -q -ff -fp -jb -j1 -tWC -tWM -O2 -OS -I$(BCCINST)/include -DNDEBUG -DWIN32
# dll >> -tWD
LN_OPTS = -lGn -lGi -lap -lx -L$(BCCINST)/lib
# dll >> -Tpd
! IF "$(CPU)" == "P1"
CC_OPTS = $(CC_OPTS) -5
! ELSE
CC_OPTS = $(CC_OPTS) -6
! ENDIF

! IF "$(WARN)" == "OFF"
CC_OPTS = $(CC_OPTS) -w-
! ELSE
CC_OPTS = $(CC_OPTS)
! ENDIF

LN_DLL =
#$(CCINST)/lib/cw32R.lib
LN_OUT = -e
CC_OUT = -o

CC = bcc32
LN = bcc32

OFF = obj
PGM = $(T_LAME)

! ENDIF
#_______________________________________________________ Borland BCC options __


! ELSE

#__ Intel 4.5 options _________________________________________________________
#
# /YX enable automatic precompiled header file creation/usage
# /Ox maximum optimization same as /O2 without /Gfy
# /O2 same as /Gfsy /Ob1gyti
# /Gd 1) make cdecl the default calling convention
# /G5 2) optimized for Pentium
# /G6 3) optimized for Pentium II/III
# /GA assume single threaded
# /Gs[n] disable stack checks for functions with <n bytes of locals
# /GF read-only string pooling optimization
# /Gy separate functions for the linker
# /Qunroll unroll loops with default heuristic
# /QIfist enable fast float to int conversion
# /QIfdiv enable patch for Pentium with FDIV erratum
# /QI0f enable patch for Pentium with 0f erratum
# /Qip 2) enable single-file IP optimizations (within files)
# /Qipo enable multi-file IP optimizations (between files)
# /Qipo_wp 4) enable entire program multi-file IP optimizations
# /QaxiMK automatic use of specialized code for PII/III, MMX, SIMD
#
# remarks:
# 1) slows speed down, not using
# 2) faster compared to 3) or 4) on Pentium MMX at 200 MHz

! IF "$(CPU)" == "P1"
CC_OPTS = /G5 /QaxM
! ELSE
CC_OPTS = /G6 /Qaxi
! ENDIF

! IF "$(VERBOSE_VEC)" != ""
CC_OPTS = $(CC_OPTS) /Qvec_verbose3
! ENDIF

! IF "$(PROF_OPT)" == "GEN"
CC_OPTS = $(CC_OPTS) /Qprof_gen
! ELSE
! IF "$(PROF_OPT)" == "USE"
CC_OPTS = $(CC_OPTS) /Qprof_use
! ENDIF
! ENDIF

! IF "$(OPT)" == "NORMAL"
CC_OPTS = $(CC_OPTS) /Qip
! ELSE
! IF "$(OPT)" == "EXTRA"
# resulting exe seems to be not faster than with NORMAL
CC_OPTS = $(CC_OPTS) /Qip /Qipo
! ELSE
! IF "$(OPT)" == "ULTRA"
# resulting exe seems to be not faster than with NORMAL
CC_OPTS = $(CC_OPTS) /Qip /Qipo_wp
! ENDIF
! ENDIF
! ENDIF

! IF "$(WARN)" == "OFF"
CC_OPTS = $(CC_OPTS) /w
! ELSE
CC_OPTS = $(CC_OPTS) /W2 /Wport
! ENDIF

CC_OPTS = /nologo /DNDEBUG /YX /GA /O2 /Gs1024
/Qunroll /Qsox- /QIfist /Qrcd $(CC_OPTS) /DFLOAT8=float

LN_OPTS = $(CC_OPTS)
LN_DLL = /LD
LN_OUT = /Fe
CC_OUT = /Fo

CC = icl
LN = icl
#_________________________________________________________ Intel 4.5 options __

! ENDIF



#-- MISC --
SNDLIB = /DLAMESNDFILE
LIBSNDFILE =

BRHIST_SWITCH = /DBRHIST
TIMER_SWITCH =

CPP_OPTS = /DHAVE_CONFIG_H -I.



#__ FRAME ANALYZER SUPPORT ____________________________________________________
#
# Assuming you have "glib-dev" and "gtk+-dev" installed and the system
# DLLs "glib-1.3.dll", "gdk-1.3.dll" and "gtk-1.3.dll" copied into the
# "WinSystem" folder
#
# To compile in the frame analyzer support, you need the above mentioned
# libraries. You can pass the appropriate path to them in GTK_DIRS.
#
! IF "$(GTK)" == "YES"
! IF "$(GTK_DIRS)" == ""
GTK_DIRS = ../src
! ENDIF
GTK_OPTS = -I$(GTK_DIRS)/glib
-I$(GTK_DIRS)/gtk+
-I$(GTK_DIRS)/gtk+/gtk
-I$(GTK_DIRS)/gtk+/gdk
GTK_LIBS = $(GTK_DIRS)/gtk+/gtk/gtk-1.3.lib
$(GTK_DIRS)/gtk+/gdk/gdk-1.3.lib
$(GTK_DIRS)/glib/glib-1.3.lib

PGM = $(T_MP3X) $(PGM)
! ELSE
! IF "$(GTK)" == ""
! MESSAGE Pass GTK=YES to build the frame analyzer. (requires installed GTK)
! ENDIF
! ENDIF
#____________________________________________________ FRAME ANALYZER SUPPORT __



#__ VORBIS SUPPORT ____________________________________________________________
! IF "$(OGG)" != ""
VORBIS = /DHAVE_VORBIS -I../vorbis/include
VORBISLIB = ../vorbis/lib/vorbis.lib
! ENDIF
#____________________________________________________________ VORBIS SUPPORT __



#__ MPG123 DECODING ___________________________________________________________
#
# uncomment the following if you want decoding support
# It's always a good idea to compile it in!
#
CPP_OPTS = $(CPP_OPTS) /DHAVE_MPGLIB /DUSE_LAYER_1 /DUSE_LAYER_2
#___________________________________________________________ MPG123 DECODING __



#__ Takehiro's IEEE hack ______________________________________________________
#
# uncomment the following to enable Takehiro's IEEE hack
# You'll want it on a x86 machine with i387 FPU
#
CPP_OPTS = $(CPP_OPTS) /DTAKEHIRO_IEEE754_HACK
#______________________________________________________ Takehiro's IEEE hack __



#__ Robert's alternate code ___________________________________________________
! IF "$(CFG)" == "RH"
CPP_OPTS = $(CPP_OPTS)
!MESSAGE there is currently no alternate code by RH
! ENDIF
#___________________________________________________ Robert's alternate code __



CC_SWITCHES = $(CC_OPTS) $(SNDLIB) $(VORBIS) $(BRHIST_SWITCH)
$(TIMER_SWITCH) $(GTK_OPTS) /DBS_FORMAT=BINARY

LN_SWITCHES = $(LN_OPTS)

lame_sources =
frontend/main.c

mpx_sources =
frontend/gpkplotting.c
frontend/gtkanal.c
frontend/mp3x.c

dll_sources =
dll/BladeMP3EncDll.c

common_sources =
frontend/portableio.c
frontend/get_audio.c
frontend/parse.c
frontend/timestatus.c
frontend/lametime.c
frontend/brhist.c

lamelib_sources =
libmp3lame/bitstream.c
libmp3lame/encoder.c
libmp3lame/fft.c
libmp3lame/id3tag.c
libmp3lame/lame.c
libmp3lame/newmdct.c
libmp3lame/psymodel.c
libmp3lame/quantize.c
libmp3lame/quantize_pvt.c
libmp3lame/set_get.c
libmp3lame/vbrquantize.c
libmp3lame/reservoir.c
libmp3lame/tables.c
libmp3lame/takehiro.c
libmp3lame/util.c
libmp3lame/vorbis_interface.c
libmp3lame/mpglib_interface.c
libmp3lame/VbrTag.c
libmp3lame/version.c

mpglib_sources =
mpglib/common.c
mpglib/dct64_i386.c
mpglib/decode_i386.c
mpglib/layer1.c
mpglib/layer2.c
mpglib/layer3.c
mpglib/tabinit.c
mpglib/interface.c



LIB_OBJ = $(lamelib_sources:.c=.obj)
MPG_OBJ = $(mpglib_sources:.c=.obj)
CMMN_OBJ = $(common_sources:.c=.obj)
LAME_OBJ = $(lame_sources:.c=.obj)
MPX_OBJ = $(mpx_sources:.c=.obj)
DLL_OBJ = $(dll_sources:.c=.obj)

.c.obj:
@$(CC) $(CPP_OPTS) $(CC_SWITCHES) -Iinclude -Ilibmp3lame -Impglib
$(CC_OUT)$@ -c $<

#__ NASM ______________________________________________________________________
#
# NASM: Netwide Assembler
#
! IF "$(ASM)" == "YES"
.SUFFIXES : .nas
.nas.obj:
@echo $<
@nasmw -f $(OFF) -i libmp3lame/i386/ -DWIN32 $< -o $@

CC_SWITCHES = $(CC_SWITCHES) /DHAVE_NASM
ASM_OBJ = $(ASM_OBJ) libmp3lame/i386/cpu_feat.obj libmp3lame/i386/scalar.obj


ASM_OBJ = $(ASM_OBJ) libmp3lame/i386/fft3dn.obj

# not yet coded
#CC_SWITCHES = $(CC_SWITCHES) /DUSE_FFTSSE
#ASM_OBJ = $(ASM_OBJ) libmp3lame/i386/fftsse.obj

#CC_SWITCHES = $(CC_SWITCHES) /DUSE_FFTFPU
#ASM_OBJ = $(ASM_OBJ) libmp3lame/i386/fftfpu.obj
! ENDIF
#______________________________________________________________________ NASM __



#__ MMX _______________________________________________________________________
#
# you need NASM but *not necessarily* a processor with MMX
# The above CPU feature detection code allows to run the same
# binary on a CPU without MMX too!
#
! IF "$(ASM)" == "YES"
! IF "$(MMX)" == "YES"
CC_SWITCHES = $(CC_SWITCHES) /DMMX_choose_table
ASM_OBJ = $(ASM_OBJ) libmp3lame/i386/choose_table.obj
! ENDIF
! ENDIF
#_______________________________________________________________________ MMX __

! MESSAGE



all : $(PGM)
@echo.
@echo --=* $(PGM) uptodate *=--
@echo.

common: $(CMMN_OBJ)
@echo.
@echo --- COMMON FRONTEND STUFF UPTODATE ---
@echo.

libA: $(LIB_OBJ)
@echo.
@echo --- LAME MP3 ENCODING LIBRARY UPTODATE ---
@echo.

libB: $(MPG_OBJ)
@echo.
@echo --- MPG123 DECODING LIBRARY UPTODATE ---
@echo.

lib: $(ASM_OBJ) libA libB

$(T_LAME) : config.h lib common $(LAME_OBJ)
@$(LN) $(LN_OUT)$@ $(LN_SWITCHES) $(LIBSNDFILE) $(VORBISLIB)
$(ASM_OBJ) $(LIB_OBJ) $(MPG_OBJ) $(CMMN_OBJ) $(LAME_OBJ)
@echo.
@echo --=* $@ ready *=--
@echo.

$(T_MP3X) : config.h lib common $(MPX_OBJ)
@$(LN) $(LN_OUT)$@ $(LN_SWITCHES) $(GTK_LIBS) $(LIBSNDFILE) $(VORBISLIB)
$(ASM_OBJ) $(LIB_OBJ) $(MPG_OBJ) $(CMMN_OBJ) $(MPX_OBJ)
@echo.
@echo --=* $@ ready *=--
@echo.

$(T_LDLL) : config.h lib $(DLL_OBJ)
@$(LN) $(LN_OUT)$@ $(LN_SWITCHES) $(LN_DLL) $(LIBSNDFILE) $(VORBISLIB)
$(ASM_OBJ) $(LIB_OBJ) $(MPG_OBJ) $(DLL_OBJ)
@echo.
@echo --=* $@ ready *=--
@echo.

config.h : configMS.h
@-copy configMS.h config.h

clean:
@-del *.exe
@-del icl.pch
@-del lame_enc.*
@-del frontend*.obj
@-del dll*.obj
@-del mpglib*.obj
@-del libmp3lame*.obj
@-del libmp3lamei386*.obj


rebuild: clean all


lame : $(T_LAME)
dll : $(T_LDLL)
mp3x : $(T_MP3X)


*****(end of file)*****