BladeEnc 0.80 released under the LGPL
Tord writes "After about half a years delay I have finally released BladeEnc 0.80 under the LGPL.
After some investigations, me and my patent ombudsman could only come to the conclusion that BladeEnc doesn't infringe any of the Swedish MP3 related patents, so I have been recommended to just go ahead with BladeEnc.
I'll explain the patent issues in more detail later. Let's just say that we have found some interesting details...
"
as long as you're happy with the fact that you'll never be a profit center there....
If you're getting "noise" from LAME you probably need to toggle the byte-order option (I forget the option, check the command-line help).
With egcs-19990524 and -O2 -funroll-loops -fomit-frame-pointer -malign-loops=2 -malign-functions=2 -malign-jumps=2
bladeenc runs twice as fast as it did before. Too bad releasing the source code didn't improve the quality too. I'm still going to have to use Lame for quality.
Answer to question #1: It doesn't matter if you code from the ground up w/o the ISO code, as long as you are using the algorithm for which they have a patent, you are infringing on their patent.
Answer to question #2: Not sure, but if the ISO code on which his implementation was based has some sort of a BSD (minus the advertising clause) or X-style license, he can release it under the GPL or LGPL.
It's even worse than the algorithm. It's the entire process of "encoding an audio stream to the mp3 format" which is patented, whatever algorithm you may use.
Software patents really suck. They prevent things like mpeg2 decoders from being released.
God, root, what is difference ?
It's good to have a free MP3 encoder library. LGPL is a complete superset of GPL; it can be made into GPL by anyone, or incorporated into GPL programs.
Something like this clearly belongs under LGPL, not GPL.
Why dosen't someone just make an encoder from the ground up under the GPL, w/ out the ISO code?
That code contains an algorithm that is the end result of a great deal of psycho-acoustical research, most of it unpublished. Further, the patent is on the algorithm. You'd have to redo the research, and then come up with a different algorithm. Possible, but not likely following the open-source model.
...phil
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
Indeed, LAME rocks. cdgrab, the world's greatest cd ripping program :>, defaults to it :)
I compiled it on Solaris with gcc(v8)/sparcworks 5.0 (v8,v8plusa -fast,-xO4/-xO5 and no option) and all came out fine All test encoding came resulted with the same output file, which played on my player.
Although my output file was 417 bytes smaller than the once encoded with v0.76. The extra bytes are at the end, and are mostly nulls: (sdiffs of od -c)
11241420 377 377 377 377 377 377 377 | 11241420 377 377 377 377 377 377 377 \0 \0 \0 \0 \0
11241427 | 11241440 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11241460 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11241500 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11241520 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11241540 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11241560 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11241600 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11241620 \0 \0 \0 \0 \0 \0 \0 \0 377 373 222 004
> 11241640 \0 i \0 \0 \0 \0 \0 \0 \r \0 \0
> 11241660 244 \0 \0 \0 \0 \0 \0 4 200 \0 \0 \0
> 11241700 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11241720 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11241740 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11241760 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11242000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11242020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11242040 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11242060 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11242100 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11242120 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11242140 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11242160 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11242200 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11242220 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11242240 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11242260 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> 11242272
But once in a while, there is a few bytes difference:
11240760 377 377 377 377 377 377 377 373 222 004 @ 200 013 | 11240760 377 377 377 377 377 377 377 373 222 004 377 200
There was even a difference in the first few bytes:
0000000 377 373 222 004 \0 \0 007 350 \0 i \0 \0 \0 | 0000000 377 373 222 004 \0 \0 \0 \0 \0 i \0 \0
0000020 \r \0 \0 \0 \0 \0 001 244 \0 \0 \0 \0 0000020 \r \0 \0 \0 \0 \0 001 244 \0 \0 \0
0000040 200 \0 \0 \0 377 377 377 377 377 377 377 377 377 3 0000040 200 \0 \0 \0 377 377 377 377 377 377 377 377 3
0000060 377 377 377 377 377 377 377 377 377 377 377 377 377 3 0000060 377 377 377 377 377 377 377 377 377 377 377 377 3
0000100 377 377 377 377 377 377 377 377 377 377 377 377 377 3 0000100 377 377 377 377 377 377 377 377 377 377 377 377 3
If you create a derived work from something that isn't technically in violation of any patents -- even if you're in a country where those laws do not apply -- I don't believe you can be held liable for any wrongdoing. In other words, b/c it was developed in Sweden, the code should be safe -- regardless of where it is developed from now on.
Isn't it?
Eviscerati.Org: All Hail the Eviscerati
This is not an advantage. Joint stereo sounds terrible, even to my audiophiles-must-die ears. I suppose if you're playing sound on your PC's internal speaker, you might not notice the difference... :-)
"I want to use software that doesn't suck." - ESR
"All software that isn't free sucks." - RMS
As with any good piece of free software,
joint-stereo can be turned off via command line
arguments.
I've used BladeEnc in the past, and all of
its output sounds too 'tinny' in the upper
frequencies. I've been using LAME for weeks now,
its quality far surpasses BladeEnc. Plus,
having been open-source for some time, I've
been able to point them to some other quality
fixes. LAME takes the cake (next to FhG perhaps)
Is LAME available for linux? From looking at the BladeEnc web page I don't
see that it supports VBR. Not knowing much about the technology, is this a
real improvement? Should I hold out on encoding my music until a VBR capable
encoder becomes available for linux?
Tony Peterson
Not to get into an Encoder-War or anything...
But have you considered that the reason that are accepting the quality of BladeEnc's output is that you haven't heard anything better?
I also used BladeEnc for a while, but I've since switched to Lame. It seems (to me) to be faster and produce better quality than BladeEnc.
Now, I'm REALLY not trying to say that everyone should use Lame, and in fact I'm thrilled that BladeEnc is being released under the LGPL (I'll download the source and do a comparison later to see how far its come since I used it). what I am saying is: Why are you ripping all of your CDs without even doing a comparison of the different options you have for encoding them first?
Again, if you didn't know about your other options, then there's nothing wrong with going ahead with what you do have, but I just hope that discerning readers out there will just step back and give the alternatives a try.
ferix
arvind rulez
Set up the process, and I'll throw in 10 bucks. Would love to send more, but I'm a poor student.
Guys, can you suggest somewhere where I can get a precompiled version of LAME? I tried downloading the ISO source and the latest patch but the stupid thing simply doesn't work. All I get when I encode my CD's (which work perfectly with BladeEnc, btw) is noise.
Perhaps I am using it wrong? Is there a reference somewhere to using the ISO command line options? I have no idea which acoustic model to specify, as none of the documentation explains how to actually USE the blasted thing.
Thanks!
UNDER Linux, not Windows or some other OS.
I would like to copy over my entire CD collection to MP3s so I can more easily access it for playing. I'm wondering what solutions there are for Linux. I've been playing with cdparanoia, but it seams to only run at 1x read speed, when my slowest CDROM is a 4x and my fastest is 16x. How can I do the CDDA data extraction at a more reasonable rate? Is there an option I missed?
I can easily write the perl scripts to drive the ripper myself, but I need the base tools working at a reasonable rate to be efficient at the ripping. I can't afford to be sitting at the computer all day feeding disks. My free time is much to scarce.
With five CPU's you only encode at half realtime? Is that really that good. I can encode at real time with my single processor Mac using VBR with Audio Catalyst including ripping.
Just wondering.
It's sort of illegal in the US, but not very. Patents more apply to commercial/mass use than personal use. I don't know the exact law, but it's similar, if stricter than, fair use copyright law. If I were you, I'd just use it. It is certainly illegal to redistribute it, though.
For both posters that were interested in LAME:
The official homepage is at
www.sulaco.org/mp3
Specifically, you can find source and binaries available
here. RPMS for
i586/glibc2.0, i586/glibc2.1 and alpha/glibc2.0 are available.
LAME compiles on Linux, Windows, Mac, and various
un*xes
Patent means no one can write a new program from the ground up where the patent holds. I believe Tord owns the copyright to all of the code.
Variable Bitrate Encoding selects the
bitrate necessary to eliminate audible distortion
for each frame. Generally it is used to provide
absolutely perfect quality without having to select
a very high bitrate. LAME allows you to tune
the quality you want (resulting in larger or smaller files)
on the commandline. For the most part, though,
it currently generates larger files using VBR
than without, so its main use is in producing high
quality mp3s, not small ones.
This is really a good day. BladeEnc was the last proprietary program I was using. Now my system can be completely free.
I was able to build BladeEnc 0.80 under OpenBSD 2.5 with no problems. Redhat 6, however, proved to be a challenge. Line 109 of main.c needed to be chopped a little, and on my ultra 10 I had to change the compile script to include -malign-jumps=4 -malign-loops=4 (instead of =2). Even so, when I run the resulting binary, I get a Segmentation fault. Same thing on my AS200. I'd like to work with the author to resolve these issues ASAP.
-- Lou Rinaldi
tenebre@cfug.org
AudioCatalyst is based on the Xing encoder, which is about 10x faster than BladeEnc. And since you're on PowerPC, you get the floating point advantage. AudioCatalyst on the Mac is currently the fastest encoding solution available to general consumers.
I too am a poor student, so I can't give much, but BladeEnc is far and away my favorite encoder. I would've registered it were it shareware, so I suppose I can kick in $20 or so for the cause.
I can't fault your logic at all. And I think the LGPL is an excellent tool to use when you want to help make a standard more open, because it is commercial software-friendly without keeping the free software community excluded from the core technology.
All I can say is, I'm very happy that the MP3 world has an accessible encoding technology. This make the position of us MP3 musician a _lot_ stronger and more independent from the RIAA.
Eviscerati.Org: All Hail the Eviscerati
I've been using the BeOS version of lame, and agree that it's the fastest non-Xing encoder I've seen. Especially with the -f switch. Sounds great too.
I'm having trouble compiling this under RH6. I first tried pgcc and then the gcc that came with RH6; both return the error:
main.c:109: initializer element is not constant
How do I fix it?
-Patrick Hearon
I asked. He said he's not currently interested
in donations, at least until the whole matter is
settled. He'll put up the final $US number when
there is one, meantime keep thinking good thoughts.
I also recently downloaded a version of LAME that
compiles in BeOS R4.5.
Haven't used it yet, but after reading things here, I am anxious to.
Just curious :)
Just wanted to mention that the Xing mp3 encoder
for Linux is available.
Supporting Linux means both boosting the open-source software that is available, and also supporting the commercial vendors brave enough to port their crown jewels to our favorite OS.
Xing makes an excellent product, and for only $20 at your favorite on-line software vendor, how can you lose?
[not a Xing employee, just a fan]
Try listening to it with headphones ;)
I used Bladeenc to rip and encode my entire CD collection (150+ cd's). It's great to hear that the source is going to be available!
Just curious, if the author is reading this, what made you release it under the LGPL rather than the GPL?
You know, I'd really love to say how much I love
bladeenc, since I use it to encode all my mp3s,
but I really can't. Not because I think it's bad,
but because it's the only encoder I've used. I
downloaded it, wrote some perl scripts, and
haven't thought about it again. Same way with
mpg123 and cdparanoia. I downloaded them all in
the same night, and started ripping all my cds.
Then I wrote a script to play a random song, and
I haven't played an actual CD again.
I wonder what's so interesting about the patents? Maybe they forgot to mention that it was for audio encoding ;)
Anyway, it's great to hear that the source is available.
I'm relying on second-hand information, but isn't the licensing fee only applicable if you're charging for your product? In other words, if you're distributing it for free, you don't have to pay for the licensing?
> isn't the licensing fee only applicable if
> you're charging for your product?
I wish it were so. For *decoders*, it is the case that you don't have to pay unless you charge. For *encoders*, you have to pay regardless. Last I checked, they charge a per-unit license fee with a minimum yearly payment of $15,000.
--
Does this mean that people will be able to build other encoders (albeit possibly illegally) using the information contained in the Bladeenc source? Was this information available before this?
The reason I'm asking is because I don't know of any other GPL/LGPL encoders out there. Are there?
It is great both to see this source released and to see that Tord thinks he is legally in the clear (I hope he's right).
I am very curious to hear the details -- particularly how they might pertain to other countries. The Fraunhofer patent is really stifling free software encoder development -- it doesn't matter how low the licensing fee is if you aren't selling your software.
--
I hope it gets a new GUI front end for Linux.. maybe gtk or Qt.... I'd do it but am to busy at this point.
Only 'flamers' flame!
This is just too good to be true!
Love you folks!
Cool, but useless.
And a configure script too, perhaps? Now that it's open-sourced, maybe we can work together to make it configure;make;make install - compatible.
Ita erat quando hic adveni.
This means that we should finally be able to build BladeEnc linked against the fast math libraries that are available! Woo hoo!
Might also make a nice GUI frontend simpler to develop, though grip is pretty nice even as it is.
-- Rick
Cheap and old CD drives read CDDA single-speed.
Get a SCSI CD-ROM: CPU usage while ripping is dramatically lower. If you encode while ripping, it makes a HUGE difference.
The following might explain what the interesting patenting stuff is about:
From: Brian Ristuccia
To: debian-legal@lists.debian.org
Subject: bladeenc
Bladeenc, a mpeg1/2 layer 3 encoder has been recently released under the
LGPL. After investigation, the author has found that Thompson's and
Franhauffer's patent claims do not apply to him in his home country.
My question is, do we have a server in a country where this package could be
hosted? Sweeden is safe. Australia might be. Germany is probably not. Where
is non-us currently located?
The times are seldom and far between, but sometimes I am really proud of my country...
Which is Ironic, because Math is my field, so if the world worked the way they say it does, I should be angry that I can't monopolize whatever I should happen to be the first to stumble upon.
Patents are an infringement on the freedom of thought.
[sorry for the AC post, but I'm at work now and don't have my password handy]
"Just curious, if the author is reading this, what made you release it under the LGPL rather than the GPL?"
Two major reasons actually:
1. BladeEnc has allready been out for a while and a large amount of BladeEnc users are using a closed source Windows ripper like Audiograbber, EAC, Easy CDDA Extractor 3 etc. All these programs are distributed as shareware and the authors have helped me promote BladeEnc. Jukka (creator of CDDA Extractor 3) actually created the DLL version of BladeEnc and Jackie (creator of Audiograbber) have been very supportive. It wouldn't be especially nice of me to suddenly turn my back against them and all the users who use BladeEnc in combination with their programs (which is probably half my userbase).
2. I'm fed up with this MP3 patent situation and those extemely expensive licenses. I want MP3's to be an open standard that can be used by both commercial and free packages. By making my code available for commercial products I do help them to keep down the cost (a number of software developers have shown the interest in purchasing the cheaper license (technology only, no code) from Fraunhofer and use BladeEnc's technology) and to make more products support the MP3 standard. I think this is very important since MP3 as a standard constantly is being fought by companies who are trying to push an even more closed format (like MS Audio, Real Audio, VQF etc) which might be better performance-wise, but would leave both the Free Software and Open Source Movement in the cold if they succeeded. Open standards, used both by free and proprietary software is essential for our success.
For another, future product I will most likely use the GPL instead.
/Tord
Hmmpf. Well, while waiting for the crowd to die down here's the skinny on a cirrus MP3 DEcoder in Si.
I've been real happy w/ bladenc, but haven't tried any others.
Chuck
try { do() || do_not(); } catch (JediException err) { yoda(err); }
If you are initializing with a non-constant, then move the expression into a function.
/* more code here .. */}
/*more code here .. */}
before.c
FILE * junk = stdout;
main(){
-----
after.c
FILE * junk;
main(){ junk = stdout
send + more == money?
So is it legal for me to use BladeEnc in the US or is that still a violation of the patents? How about LAME (a very interesting use of source, I must say)?
Or maybe I'll just wait until the bladeenc page gets updated with the information on patents.
It's not that I like software patents (I don't); I just try to obey laws.
All this legal crap kinda scares me. Why dosen't someone just make an encoder from the ground up under the GPL, w/ out the ISO code? (I would try but I'm not that good of a coder yet)
My other Question is how can Tord LGPL all of the code, he dosen't have the copyright to all of it right?
my other penis is a vagina
Did anyone else see the Trod's page where he talks
about these groundless patent threats? Check it
out at http://home8.swipnet.se/~w-82625. In that
page Tord says that these legal issues will cost
him around 1,000 dollars (I assume he means U.S.
dollars). I use bladeenc all the time and I
would like to help Tord defend himself on the
legal front. I would be willing to put up the
first 100 dollars for a "bladeenc legal defense fund". Who here is with me?
Mo DeJong
dejong@cs.umn.edu
Perhaps you should've explained what joint stereo does...
In a nutshell, it plays back the low frequencies in mono. The idea is that the human ear doesn't perceive the direction of low frequencies very well. So you can use this technique to improve compression.
If you have a subwoofer / satellite system at home, then joint stereo is going to sound perfectly fine.
On other systems, the only way you'll really notice a difference is if you have your woofers placed with a good deal of separation in the room, and your listening spot is in the so-called sweet spot. Otherwise the low frequencies will just fill the room and you won't be able to perceive much of a difference.
In car-audio, bridging to mono is used all the time for subwoofers because there is no sweet-spot in a car and the bass is going to be all around you.
- Speed