I have bith the cakewalk 64 bit and lame 3.97 installed and running in my DAW... I only use the cakewalk myself but ive had readon to use lame free encoder a few times...

I much prefer using the cakewalk encoder...

I was in a hurry when i setup the laptop in tge middle of the night so i installed lame there...

I just searched for the activation code there but couldnt find it so late tomorrow i hope to contact customer support and get another copy...

There is no entry in my peoducts as i didnt buy it separately. I got it long ago i think with ProAudio7 or there about? But they continue to authorize me us as paid...

Thanks guys...

I belueve you can run as many external encoders as you wish to install. Sonar after mixing, simply hands off the wav file to whichever encoder is selected with the command line supplued in the configurator...

Keni

Yes that's right apparently.

Previously that may have been useful as Cakewalk used an older version of Lame. With Sonar 2015 Cambridge, several MP3 enhancements were added including the update of TTSLAME.dll to using Lame v. 3.99

Thanks mudgel...

Yes, i remember reading about it... For my use i wasnt having any trouble with 3.97... Does 3.99 make better sounding mp3s somehow?

I read the additional support it added but i dont remember thinking any of it affected me...

That said, i'm glad to have the updated version and look forward to activating it on my laptop as well as my DAW... That woukd be very handy for me...

Keni

Mudgel:
 
When you select "MP3" using the "Files of Type" dropdown menu, you are selecting the Cakewalk MP3 Encoder to do the encoding. You select Arron's encoder when you select one of the files with the long names, such as "MP3 256 kbps-keep wav file," "MP3 256 kbps-discard wav file," "Mp3 Variable Bit Rate-quality 8 of 10," etc..

Thanks Thomas, I understood after you mentioned it. It hasn't been since Sonar 8 or 7 that I've used the external encoder and I just couldn't wrap my head around how they present in the export menu. Once you mentioned it I realised straight away. So after a million and one posts I'm all OK and have it sorted in my big head.

I've been reading the various tutorials and one even goes back to Sonar 4. That's 11 years ago so while in principle the instructions haven't changed file locations and references have. So I'm looking at putting together a package that will put the lame dll, the encoder config files and instructions all in one zip file. Or at the very least confirm where the encoder config files are in today's installations, link to lame and write up a current tutorial. What do you think?

Well, There are 3 popular and useful ways to encode mp3 files when using SONAR, to me.
 
1) The easiest is to use the Cakewalk MP3 Encoder (with comprehensive ID3 support), and it's convenient to use it, since you can stay within SONAR, but that's if a user pays for the Activator. And the GUI could use some eye candy attention. :) Cake could make it look sharp like other GUIs they make, like the sharp ones they make for VSTs/Pro Channel modules, for example. Make it look Professional with a good eye candy appearance.
 
2) Using Aaron's MP3 Patch is the next easiest way (How to use that method is, basically, explained in my post #96 of this thread), but that method has limited ID3 Info encoding options, just 3 fields, Namely: Author, Title of track, and Copyright year.
 
3) The Cakewalk External Encoder Configuration Utility. That's the hardest of the 3 to use, as a user has to figure out how to use those Lame command line variables. I flee from that command line stuff, so I can't be much help there. But I mention part of what to do in my post #100 of this thread.
 
If you have it in mind to make some tutorial for users, that's a decent thing to do. If I can be of any assistance, let me know. It's the least I can do, since I was of no use to you during your SONAR X1 trials. :) (When you were having serious issues running X1).

Ah X1. You remember that time hey! I sure do. Man that was about 4 months of hell.
My whinging got so bad I got labeled a pest. Haha. There was no letup. I wish that the Cakewalk of today was around then. Anyway that's history and X1c fixed it and then X1d really hit the nail on the head and it was pretty good going once I let go of 8.5.3. Wow compare that dog of a program to X3 and Sonar 2015. No real comparison.

I think I will make a new tutorial with screen grabs and such. Sort it out once and for all.

I sympathize with the effort to make MP3 encoding as simple and as painless as possible, but I also think it's pretty important to understand the encoding process and what it is doing to your sound. The reality is that MP3 encoding will have some level of impact on the quality of the sound, period. Given that, it doesn't make any sense to me that a guy that would spend hours and hours monkeying with various compressor plug-ins and settings, judging the subtle qualities of each tiny change would then blindly mash the final product through a meat-grinder MP3 conversion process where any such subtleties are utterly lost.
 
Another thing to consider is that there are different contexts for your output. Maybe you're producing stuff for your band to listen to only and don't really care about file sizes and want just the highest quality you can get. Or maybe you're deploying to a site like Reverb Nation where keeping the file size under the free-service limit while ensuring decent qualit is important. Or maybe you're producing downloads for sale and you need to leverage ID3 tags so that end users get the fullest experience possible.
 
So yeah, let's leverage tools that helps make encoding easy to use but it makes a lot of sense to me to invest a little time in understanding what's happening when you encode. That's why I applaud mudgel's efforts to shed some light on this subject.
 
One thing I often do is use Sonar to render everything to a WAV file and do MP3 conversions later outside of Sonar. I do this because some encoding scenarios require different bitrates because of file size limitations, or because I want to encode groups of files for an album-style distribution using ID3 tags for track ID's and to assure similar quality settings across tracks. Achieving this level of flexibility is certainly possible with all of the options presented in this thread but for me it's just much  easier to open up a command window and do it the old-fashioned way. However you choose to do it, understanding the quality settings are important.
 
So for those of you who want better control of the encoding process, this is a short summary of the recommendations for the LAME encoder that I pulled from the help docs and massaged a bit to make it somewhat less geeky:
 
There are three basic ways to encode an MP3 file with LAME:
 
• Constant Bitrate: CBR encoding is the basic encoding mode of MP3. The bitrate is kept constant across the entire file, which means the same number of bits is allocated to encode each second of audio, resulting in a predictable file size for a given duration. CBR is useful for people who are concerned about maintaining maximum compatibility, especially with certain streaming applications and some hardware-based decoders that don't reliably support VBR.
 
• Variable Bitrate (VBR mode): The user chooses a desired quality level instead of a bitrate. The encoder will change the bitrate to a higher or lower one whenever the audio file is more or less complex. The main advantage of using VBR is that the encoder will use the smallest amount of bytes needed to keep the asked quality. The inconvenience is that the file size is quite unpredictable, and can change from file to file in more than 50kbps.
 
• Variable Bitrate (ABR mode): ABR is a mix between CBR and VBR. ABR encoding is desirable for users who want the general benefits of VBR (an optimum bitrate from frame to frame) but with a relatively predictable file size like they would get with constant bitrate (CBR), and a greater preference for bitrates that are near a desired target.  
 
Recommendations for quality:
 
Best quality, "archiving": CBR 320 is the strongest setting for MP3, with the lowest risk of artifacts. Sample Sonar External Encoder Utility command line:
 
lame -b320 %I %O
 
However, with the exception of a few situations, quality is rarely better than the highest VBR quality profiles described below.
 
• High quality, HiFi, home or quiet listening : -V0 (avg. 245 kbps) or -V1 (avg. 225 kbps) or -V2 (avg. 190 kbps) or  -V3 (avg. 175 kbps).   These settings are considered to produce transparent encoding (transparent = most people can't distinguish the MP3 from the original in an ABX blind test). Audible differences between these presets exist, but are rare.
 
• Portable, background noise and low bitrate requirement, small sizes : -V4 (avg. 160 kbps) or -V5 (avg. 130 kbps) or  -V6 (avg. 115 kbps) -V6 produces an "acceptable" quality, while -V4 should be close to perceptual transparency.
 
• Very low bitrate, small sizes, eg. for voice, radio, mono encoding : --abr 80 (stereo) or --abr 56 -m m (mono) For very low bitrates, up to 100kbps, ABR is most often the best solution.
 
Sample Sonar External Encoder Utility command line:
 
lame -V0 %I %O
 
Sorry to be so verbose and I hope someone finds this useful.
 
 
 

Do you mind if I use your post as additional info for when I put an MP3 package together? I was actually going to add info on all the switches for command line interaction, despite any GUI the work is still done there.

Feel free, I 'm largely paraphrasing the help docs anyway. Let me know if you'd like to farm out some of the work.