BladeEnc News Section

Latest Version: 0.82











Note!  The newsletter is currently down (both subscription system and sending). You can still subscribe, but you won't be added to the list or receive any confirmation until I have fixed a few things here...

Current subscribers: Better check this page for news until you receive a letter saying that it's up again.
 
 

Subscribe to BladeEnc Newsletter!

Subscribe to BladeEnc newsletter and get the latest BladeEnc related news sent directly to your e-mail address!
 
Subscribe
Just click the above link and send the e-mail that pops up to start your subscription to BladeEnc Newsletter. You don't need to enter anything in the message field.
Cancel Subscription
Click on the above link and send the e-mail that pops up to cancel your subscription.

Both when you subscribe and cancel your subscription you should make sure that you are sending your letter from the e-mail address that you want to be affected. Within a few days you should get an e-mail confirming your subscription/cancellation. I guarantee that your e-mail address will be used for nothing except sending you information that is related to BladeEnc.
 
 
 
Latest News
 
1999-10-24   Back from England and some updates...

Yes! I'm now finally back from my trip from England, in fact, I have been back for about two weeks now, but I have been busy catching up on a lot of things (including my e-mail). 

I've made quite a number of changes in the code during my stay in England. I haven't put it online yet, but 0.86-unstable should be up later tonight or tomorrow. I also think it's really about time to make a new stable update, but I really need to fix some things first, like a slight quality degradation compared to 0.82, so it might still take some time...

As you've probably noticed I've also moved my homepage to http://hem.bredband.net/tord which is the place provided by my new ISP. It's really about time since I now have a quite spiffy 24 hour internet connection (have an effective transfer rate of more than 400 kilobyte/second!) and the old one had to be updated through a modem connection for security reasons. So I guess I'll be updating the pages a little bit more often from now on. :)

If you have bookmarked www.bladeenc.cjb.net or bladeenc.cjb.net you won't need to update your bookmarks since those are virtual adresses which automatically will transfer you to these pages later on. However, if you have bookmarked http://home8.swipnet.se/~w-82625/ you should definitely change it to http://bladeenc.cjb.net. Don't bookmark http://hem.bredband.net/tord since that is a static adress and these pages are quite likely to move again before the end of the year.

Some minor updates have been made to these pages. David Jamroga has been so kind to read through these pages and correct any spelling errors he could find. Thanks! I've also updated the FAQ a bit (so I guess there are some new spelling errors *grin*), but the rest of the pages (quality, frontends, speed comparisons etc) are still quite out of date.

In the source archive you can now also find the source for the DLL-wrapper.

Some new ports of 0.82 have also been provided. An Irix6 port has been submitted by Thomas Svedberg, an MS-DOS port has been done by Matt Craven and a new OS/2 port has (as usually) been provided by Mikael Kjellstr÷m.

I have some more ports in my inbox which I'll put online later... 

1999-08-07   Delphi Headers now available & 0.85-Unstable in the source archive

Delphi headers for BladeEnc.DLL can now be downloaded from the source archive thanks to Sinan Karaca who sent me a working Delphi header. 

It was originally converted from the C-Headers to Delphi by Jack Kallestrup who released it on the net. Unfortunately it contained an error which caused memory leaks, crashes etc. which Sinan now has fixed and sent to me in order to make a working version available to anyone.

I've also updated the source a bit and released 0.85-Unstable which you also can find in the source archive. As with all unstable releases, don't use this for any serious encodings since it might contain new bugs affecting the output.

It's now quite improved compared to 0.82, so I think it will be time for some serious testing and a new stable release when I get back from England.

Well, now I better get this online and start to pack my bags. It's 21:27 and I'm leaving 12:00 tomorrow...
 

1999-08-07   Business trip to England. Staying for a LOOOONG time...

I have to make a business trip to England tomorrow and I'll be staying for a very long time, possibly two months.

I haven't managed to make any arrangements yet that will allow me to update these pages or work on BladeEnc while I'm on the islands, so it's quite possible that I'll be completely cut off from any work on BladeEnc until I get back. :(

I'll be coming home a few weekends during this time, but then I will probably have no time for BladeEnc, so don't expect any updates for some time to come...
 

1999-07-30   0.84-Unstable in the source archive

BladeEnc 0.84-Unstable source code can now be found in the source archive for those who might be interested. Please remember that this is an unstable version, not meant for widespread usage yet. That said, I honestly think that it is rock solid, but it could do with some more testing before it is released.

Changes described in the CHANGES file in the source archive.
 

1999-07-30   BeOS R4, Linux PPC and BSD/OS binaries now available

BladeEnc 0.82 has now been compiled for BeOS Release 4, Linux PPC and BSD/OS 4.x. You can (of course) find them in my download section.

Thanks to Marc Schefer for the BeOS binary, Steven M. Schultz for the BSD/OS binary and Rich West for the one for LinuxPPC.
 

1999-07-27   New DLLs, Alpha NT port and Solaris ports

A new Windows DLL, based on the 0.82 engine can now be downloaded from my download page. An Alpha NT DLL has also been provided as well as a new Alpha NT executable.

The Solaris ports (both SuperSparc and UltraSparc) have been recompiled using Workshop C 5.0 and that way gained a notable speed increase.

New Solaris ports were provided by Serg 'Ice' Tsyganenko and the Alpha stuff was done by Lennart Börjeson

I've also put up a new version of the source code (0.83-unstable, although i'm quite sure that it's as stable as 0.82) that isn't ready for mass consumption yet, but those who wants to play around with it are welcome. Changes described in the CHANGES file in the source archive.
 

1999-07-23   Windows and Solaris binaries of 0.82 now available

Windows (Intel only, Alpha NT version is coming soon) and Solaris (both Super- and UltraSparc) binaries of BladeEnc 0.82 are now available for download.

The Windows binary has been done by me and the Solaris binaries have been provided by Marcos Theophylactou.

I've also fixed a minor compilation problem and put up an updated version of the source.
 

1999-07-22   BladeEnc 0.82 released! (bugfix release)

I've finally fixed the skipping header bug of 0.80 and 0.81, so I now release 0.82 that definitely should be free from this kind of embarrassing bugs.

Source code and linux-intel binaries are immediately available and a windows version should be uploaded by tomorrow.
BladeEnc 0.82 also contains some other small fixes, provided by volunteers. See the changelog at the download page for full details.

An unknown number of volunteers have been working on optimizing BladeEnc and I have now received two very interesting patches that are claimed to speed up BladeEnc notably, so you can expect some speed improvements for the next version.

Just need to take a close look at them and make sure that they don't affect quality in a negative way before I include them...

 

1999-07-04   Bug affecting output present in BladeEnc 0.80 & 0.81!

I'm really sorry about this, but there is still a quite serious bug left in 0.81...

This one gives the result that the first frame header (and possibly some others further down the MP3 file) gets lost. This might sound serious, but in most cases you won't notice anything. The sound quality is still the same except that it might skip a few milliseconds of music when a frame header gets lost and another few milliseconds might be of a slightly lower quality. This slight difference will in 99% of the cases be impossible to hear.

However, this bug is dangerous in another way since the lack of that header makes the bitstream and the headers further down the line get slightly out of sync. This is automatically corrected after just a few frames, but the frames that are affected will have some incorrect data in their headers which might confuse the player. All known players handles this nicely and goes on playing the bitstream without any trouble and some of them (for example mpg123) also prints a discrete error message.

However, there might be either present or future players (software or hardware)  or tools that won't be able to handle these slightly screwed up mp3s and that's the reason for this warning.

I don't see any need for anyone to recompress any mp3's generated with BladeEnc 0.81 unless you run into trouble, but do advise everyone to either downgrade to BladeEnc 0.76 or wait until 0.82 is released (which should be within just a few days).

You might wonder how this bug managed to sneak in since I always compare the output of a new version with the output of the previous one. The reason is that I made these changes on a laptop without my ordinary development tools over the Christmas holiday. Since I didn't have a tool for comparing two binary files accessible I took the quick route and just compared the last 10-20 bytes by hand. Since the encoding of each frame is depending on the result from the previous one we normally get a chaos effect where even extremely small changes in the process generates totally different frames at the end of the file. But since only a few bytes in the headers had changed and not the bitstream we didn't get this chaos effect. The last bytes of the files were identical anyway! :(

Like all the other serious bugs it was introduced during the vast internal changes that were made for BladeEnc 0.80, but I didn't get aware of it until after 0.81 had been released. It was reported to me within 24 hours, but I mistakenly thought that the effect was caused by another bug that was fixed in 0.81.

 

1999-06-30   Serious bugs in 0.80 discovered - 0.81 released!

Ooops!  Seems like I've done some real blunders with 0.80...

0.80 had some SERIOUS bugs:

  • Broken MP3's were generated by all files in the batch except for the first.
  • Some files couldn't be encoded due to BitHolder overflow.
  • Feeding BladeEnc with 8-bit samples caused crashes.
  • All AIFF-files were rejected.
I'm really sorry for all these errors, I simply have had too much to do lately and haven't had time to really test all the changes I made. :(

Also, a big THANK YOU to all who downloaded the source code and found those bugs for me, you really prove that the open source model works!

As a result of this I've already released BladeEnc 0.81, which has fixed all these bugs and few other minor issues (see the changelog at my download page). I seriously recommend everyone to immediately upgrade to 0.81!

I haven't got a Windows version of 0.81 yet since I don't have Windows installed at home, so I've temporarily changed back the Windows binary to 0.76. I'll compile a new Windows version at work tomorrow and put it online.

Once again, sorry for all those bugs and any trouble it might have caused you...
 

1999-06-28   BladeEnc 0.80 Released!   Source code available for download!

So, after almost half a years wait I have finally released a new version of BladeEnc!

This is the first release under the LGPL license and I hope it will signal the start of a new era for BladeEnc. The source code is available for download for anyone who wants to take a look at it and people who wants to contribute to BladeEnc's development are welcome to make improvements and send back the code. Take a look at the Source Code section of my homepage for more details.

The only versions currently available are the Windows version and various versions for Linux, but this will hopefully change quickly now when everyone can download the code... :)

Don't ask me when a new DLL will be available, it won't take too long...
 

I guess some of you wonders what happened with the patent issues. Well, after having looked through all the papers with my patent ombudsman and discussed the issue for a few hours we came to the conclusion that BladeEnc doesn't breach their patents. Not so much depending on the fact that it's software only, but due to some interesting details in their patent demands (which is the most central part of the patent papers). I don't want to go too much into detail yet since we still haven't resolved this issue once and for all (we still need to send some papers to the patent holders, specifying our conclusions and give them a chance to respond), but I have been recommended to just go on and release both the new version and the source code.

However, that doesn't necessarily mean that it's fully legal for you to download and use BladeEnc since the patents in your country might be different. Also, although BladeEnc in itself is a fully legal product here in Sweden, you might still make yourself guilty of patent infringements if you use it for some very specific tasks.

I'll explain everything more in detail when things have cleared up a bit and I'm not as tired as I am tonight.
 

1999-05-16   Fix for broken CRC on the way!

It seems like the CRC calculation routines in the ISO reference source was broken, making it just write zeroes instead of the checksum when the CRC-switch was enabled. This has unfortunately been inherited to all the ISO-based encoders like BladeEnc, 8Hz, mpegEnc etc.

I was made aware of this about half a year ago, but never fixed it because of five reasons:

  1. Lack of time.
  2. Lack of knowledge of how some parts of the encoding process worked meant that I didn't know how to fix it.
  3. No player or tool seemed to bother, it all worked fine anyway, making me believe that it was commonly accepted that if the CRC-code was zero it should be ignored and not considered to be an error.
  4. Nobody seemed to be using the CRC-switch anyway.
  5. I recognized that this CRC-data could be filled in by a tool even after the MP3 file had been generated, so the problem could be solved later on if necessary without anyone having to throw away their MP3-files
However, that has all changed now with Fraunhofer's latest routines that (in accordance with the standard), skips all frames with incorrect CRC-data, making products using it (like the latest version of WinAmp and some of the hardware players like Rio) just play silence.

I'm now working on a tool that will fix these MP3 files and I'll release it (with source code) as soon as it's finished, hopefully within a few days.
So don't delete or re-encode your files if they have been encoded with the CRC-switch enabled, this also goes for MP3 files encoded using all the other ISO based encoders, which also can be fixed with this tool.

BladeEnc 0.80 will of course have correct CRC calculation. In the meantime I recommend you to either not enable the -CRC switch on any new files you encode or run this tool afterwards.

 

1999-05-16   Updated Homepage and What's up?!

Thought it was about time I wrote something, telling people what's going on and why I haven't updated BladeEnc or these pages for many months now.

First of all, I've been busy, terribly busy. For those who doesn't know it I'm working as programmer and project manager for a swedish game developer called UDS and for the last 20 months I've been responsible for what's going to be Codemaster's big release this Autumn, namely a game for PlayStation and PC called "No Fear Downhill Mountainbiking". This project currently takes an awful lot of my time and when I have some time left I'm often too exhausted to dig into the BladeEnc code.
 

Switched to Linux

I've been keeping an eye on Linux' progress during the last months and been really eager to switch over from Windows and a few months ago I finally took the big step. I've had Red Hat 5 installed on a second partition before, but since I also had Windows I never took the time to really dig into it, but now when I got myself a second computer I decided to only install Linux on it and force myself to learn the system.

It's been a rough ride with many hours of reading documentation, experimenting and reinstalling everything from scratch a few times, but now I got it all running the way I want and learnt everything I need to know, I find that I really like it! :)

For those of you who wants to try Linux I can really recommend a distribution called Mandrake. I currently use Mandrake 5.3, but 6.0 is in the works and contains a lot of improvements. I also recommend you to do some serious reading first if you (like me) don't have any earlier experience of UNIX and have a friend who knows Linux to help you install it since you can screw up your system royally if you don't know what you're doing.

What this means for BladeEnc is that I'll take care of the Linux i386 version myself and make it more of a standard Linux program with stdio-support, manpages etc. The Windows version won't suffer because of this. I know that most of my users are running Windows and I'll continue to compile the Windows version myself and keep it up-to-date.
 

Version 0.80 in the pipeline

Despite my lack of time I have done some improvements to BladeEnc and when I look at my changelog it's actually quite a few. The most noticeable features are that it now woks better under UNIX-systems (doesn't fuck up the terminal anymore and CTRL-Z, CTRL-C etc works as it should). supports streams (both stdin and stdout), some bugfixes and the fact that I've totally rewritten how the commandline is read, making it much more flexible. You can now specify individual output files and bitrates for each file in the batch and it remains backwards compatible with both the old BladeEnc and L3Enc commandlines. However, this version will not be released until my new patent problems have been resolved...
 

New patent problems. :-(

I'm having a new situation with the MP3 patent holders (mostly Thomson and Fraunhofer). 

They contacted me once again a few months ago, saying that hadn't answered their earlier letter (which I had) and repeated their demands. I answered this letter promptly, saying that I indeed had answered their previous letter and repeated my demand that they specify what patents I might be infringing so that I can investigate it further. 

This time I took the precaution to enable Netscapes "send receipt upon arrival" and "send receipt upon read" options. Just five minutes later I got a receipt from their web server saying that the letter had landed in the correct mailbox. I then waited two weeks for either a reply or the "has been read receipt" but never received any of them. I'm quite sure they read it, but didn't want to give me any indication of it. (I guess it could be seen as an indirect acceptance of me using the patents if it could be proven that they had read my letter but didn't answer, but I'm not a lawyer so I really don't know).

I then decided that I didn't want them to repeat the same procedure once again (and possibly threaten me with a trial), so I wrote them a new letter, telling them that I was still waiting for their answer and adding a line saying that I would consider all their demands to be void until they had specified what patents I might be infringing.

That got things moving. Just a few days later I got what seems to be a complete list of all their MP3 related patents. To my surprise I found that this list included a large number of european patents related to MP3 encoding that were registered as accepted by the Swedish patent authorities! :(

After some brief phone conversations with "Patent & Registreringsverket" (the Swedish patent and trademark authorities) I could just establish the fact that they had valid, registered patents on MP3 encoding in sweden, despite the fact that the law clearly says that software-only implementations and mathematical algorithms can't be covered by swedish patents! The people I spoke to were very helpful and knew the rules well, but could only agree that this whole situation seemed quite bizarre. I decided to order copies of all these patents so that I could investigate them myself at home and a few weeks later they arrived (something went wrong, so I had to order them again after about two weeks).

I had no problem to see that these patents indeed described the exact process needed to generate MP3 files, so I then decided to contact a "patentombud" (an expert on the legalities and issues surrounding patents). After having described the situation for him, he said that these patents most likely were fully valid, but that it was very doubtful if they could be applied on my situation (if some kind of hardware was involved the situation would have been different though). However, he needs to look into the details in order to help me, so I have now decided to hire him and will send him the papers on Monday. Hopefully he will come to the conclusion that I can happily continue developing BladeEnc, but if not, he will always be able to help me find the best possible solution. This initial investigation will cost me somewhere around $500-$1000 :(

Although this situation is very irritating for the moment, I'm glad to finally be able to shed some light on this situation so I finally get to know exactly what I can do and what I can't. I've found a lot of possible solutions which I'm going to discuss with my patentombud and although I don't want to give away any details yet, I must say that I'm confident we'll come out on top of this. 
 

Source release

The source for 0.80 will be released at the same time as the binary. Can't promise any date though since I want to solve this patent issue first and have so much to do at work.
 

Homepage updated

I've just updated some parts of my homepage, especially the frontend section where I've added a whole bunch of new programs and fixed a few broken links. I can really recommend the Windows users among you to try Exact Audio Copy since this ripper both is free to use and can guarantee 100% accurate ripping without glitches! Us Linux users can of course use CD-Paranoia instead... ;)

 

Older news...