Skip to content

Is F4I in violation of the LGPL? - Part III

"Frank" posted the following comment to my last update.

"What does this code fragment do? It accesses data that is well-defined by an open specification. There is little leeway for a software developer to do things differently. So far, this may be coincidence, or a case of developers being "inspired" by looking at other source code -- like the famous "stolen" Unix code fragments in Linux. This is an invitation for more research, yes, but I don't see a smoking gun just yet."

This is a valid concern and I wanted to address this anyway, so let's do it right here. I think it's important enough to write a new update instead of just replying to Frank.

I've produced a complete annotated disassembly of the function in question. It matches the function from the LAME code 99%. I say 99% because there are differences which can be reasonably explained by common compiler optimization techniques. I've mentioned these techniques in the annotated disassembly where appropriate.

If the 99%/100% match of a 90 lines C function is a coincidence it goes beyond what I'm capable to detect using my tools.

Click here for the LAME source code.
Click here for the annotated disassembly.

Edit: I want to ask the people familiar with the LAME function in question something. Look at the following four lines from the LAME source code:

	if( buf[0] != VBRTag[0] && buf[0] != VBRTag2[0] ) return 0;    / fail /
	if( buf[1] != VBRTag[1] && buf[1] != VBRTag2[1]) return 0;    /* header not found*/
	if( buf[2] != VBRTag[2] && buf[2] != VBRTag2[2]) return 0;
	if( buf[3] != VBRTag[3] && buf[3] != VBRTag2[3]) return 0;

This piece of code attempts to check if buf contains 'Xing' or 'Info'. I don't know about the underlying data structures but the way it checks looks wrong to me. This piece of code passes if buf is a combination of 'Xing' and 'Info', like 'Iing' or 'Xnfo' which is probably not the desired functionality. Can anybody confirm that this is a bug or is not a bug? Because if it's a bug it's also part of the F4I code. This would solidify the assumption that the code was stolen from LAME even more.

Edit: OK guys, I'm going to proclaim victory now as I've found undeniable proof that this match is not a coincidence. I just took the the functions GetVbrTag and ExtractI4 from the LAME code and compiled them myself using the freely available Visual C++ 2003 commandline tools. The only compiler parameter I used is /Ox to turn on maximum optimizations. The resulting code is byte for byte the code from the F4I OCX file. Including all my correctly predicted compiler optimizations (function inlining, if-clause merging, operation re-ordering, ...).

Click here to see the disassembly of my own compiled version of the LAME code. It matches the disassembly posted earlier perfectly. Note that I didn't bother to re-name variables or to insert comments.

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

Gabriel Bouvigne on :

I can confirm that the fact that Lame detects "mixed combinations" of "Xing" and "Info" is a bug on our side.

sp on :

Thanks for the confirmation. A propagated bug is of course another relatively obvious hint that code was copied.

Of course it's not like there's any doubt at this point thanks to the recent findings.

Add Comment

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
BBCode format allowed
Form options

Submitted comments will be subject to moderation before being displayed.