My reference file (a 79 min wav from a pop compilation CD) came down from 62.86% to 62.78%, so only 0.08% instead of 0.6%. Compression time was quite a bit less here, however.

Hans

Edit: ehm, the url: http://www.lossless-audio.com

the 0.3/0.6% improvement claim was based on a test set of 8 files from a range of genres. one of the files is of classical piano music and it was this that improved the most between versions 0.2 and 0.3. I guess your result shows that for normal pop music the difference is not so great.

Hello Michael, good to see you appear here again ultimately!

Regardless how much the improvement was, la's compressed files are the top if nothing else matters.
This graph shows the compression/encoding time relation of the latest lossless formats, with abovementioned album:

(Edit: graphs are further below now)

I found a tracklist here.

Hans

thats a pretty nice graph you've got there. draw a border round all the bottommost+rightmost points and you can pick your compressor of choice depending on the speed/compression you desire (if speed/compression are all you're looking at of course).

btw, does anyone know of some good comparisons? i'd like to link to some independant ones from my site but haven't found any (except for stuff pasted in forums such as this graph which i can't really link to) which have included La yet.

http://home.wanadoo.nl/~w.speek/comparison.htm

Compression time / Compression ratio is one important aspect.
Another is Decompression time / Compression ratio.
Some compression programs have similar speeds for compression and
decompression (OptimFROG, Monkey's Audio), otther decompress much faster
than they compress (FLAC, LPAC, Shorten).
A compression speed below 1.0 (below realtime) may be acceptable,
a decompression speed below 1.0 is unusable.

Oh so true Diocletian.
I shall spend another weekend or so compressing again AND decompressing as well this time

Instead of wasting a weekend for this, I ran this batchfile overnight to do all the (de-)compressing. Then entered the file creation times and sizes in an excel worksheet. Because the PC was left untouched during this, the results can be trusted more, so I removed the graph in my first post. Here are the new graphs:


Some points are cluttering together, I hope the readability is still enough.
What shows a.o. is that flac indeed decompresses very fast.

Then I did a check on winamp seekability with this huge 79 min file, by starting play and then pulling the slider halfway:
shn, ape, flac and rka: seek 'immediately'.
la: seeks within a second since plugin v0.3c. CPU usage 60%.
ofr: takes about 3 seconds silence, then plays ok. CPU usage of ofr-4 25%.
pac: takes about 15 seconds silence, then plays ok. With a 5 min track, seeks within a second.
wv: seeking sounds like fastforwarding of a CD player, it takes a long time.

Hans

Edit: some additions and corrections, see further down. Above graphs are now based on the average of several albums, see this webpage.

Michael, any chance to see La as open-source cross-platform codec?
There are so many lossless compressors already, that in order to distinguish from the mass, you really should go open-source and cross-platform.
Imo that would be great...

Hans, with LPAC default is without random access. If you add the -r switch to the command line the files will/should be seekable. WavPack doesn't have the option to add seeking points. I don't know why OptimFrog and LA are not better seekable, but my guess is that OptimFrog adds less seeking points than other formats and LA has such high CPU usage that seeking doesn't work.

Thanks for that info, Speek. The -r switch of LPAC added about 0.3%, and the seek to halfway took about 15 seconds. With mode 1 (fast), -r doesn't work it seems because file size was equal and no seeking.

I replaced the pac graph with the seekable results, since most other can seek too.
Added winrar. And updated the seek comments with results of 5 minute files, if different.

actually the CPU usage doesn't have anything to do with seekability, at least in La's case. the reason seeking doesn't work is just a bug in the winamp plugin due to the huge file size (i never tested with a 79 minute .wav before). i'll put a fix in the next version.

Hmm.. You calmly dodged my open source question.
Any possibility in the future? Or do you want to keep it closed?

Sorry, I missed that question (honest). Its something I get asked quite a bit.

Yeah, I'm not intending to make it open source right now sorry. I know a lot people think that it needs to be open source to gain any kind of acceptance. While I understand the benefits, I don't think it makes a great difference.

The great thing about lossless audio compression is you can just encode with whatever does the job best at the time, and if the makers of the program you encoded with sell their soul to evil or whatever you can always transcode and you've lost nothing except a bit of time.

If I ever reach the stage where I have no more time / desire to work on and maintain the program, I will make it open source. I don't know if that allays anybody's fears.

Regarding your other point, that it should be open-platform, I've already got it working under linux, and will release a linux version as soon as I get the xmms plugin working.

Hmm, ok, thanks for answering. Personally I think it makes a great difference, like night and day..

La could become known as the best lossless compressor if open sourced, and the userbase probably would skyrocket compared to the current userbase. By keeping it closed, it will remain marginal of marginals compressor like RKAU and OptimFrog:
http://www.hydrogenaudio.org/forums/index....=ST&f=19&t=3918
FLAC would be there with 0-2 votes if it weren't open source... That's what makes the difference imo.

Of course you have every right to keep it closed. But hope never dies..

Michael,

It sure would be nice to have ID3 tagging with your format. I ripped some tracks on EAC and added ID3v1.1 to them. They play fine in Winamp but your plugin doesn't read the tag.

~ Darwyn

sure. i think i should be able to throw it in the next version - i just had a bit of a look at how they work, and i didn't realise that ID3 tags were so simple before (that they're just thrown on the end of the file, so i can just add some code to the plugin and no changes are necessary to the rest of the program ... correct me if i'm wrong here).

I think it would be better to support ape2 tags instead... It's a much better system really...It would make la my lossless format of choice.

i'm no expert in tagging systems as i've never bothered to use them myself. i'd have to look into how ape2 tags work, and whether its ok if i use them. presumably its possible to support both types right?

It is.
MusePack already does.

It's hard to maintain a closed-source project on Linux. The binary you create may work for you but will most certainly not for a majority of users. Unless you plan on installing many distros and making many package flavors yourself it just won't work for most people. Static linkage can help a little, but Linux is really just a kernel and there is a great deal of variation even in the system libraries. The XMMS plugin will be even harder because that must be a shared library. And to top it off, most Linux users do not trust binaries that don't have source, with good reason.

Believe me, FLAC is open source and runs in all kinds of places, even hardware players, and I still get platform-related problem reports when things change. If I had to break down the amount of development time I spend on it its probably 40% build-related (keeping the source base current with latest tools and cross-platform), 30% test code and testing, 20% docs, 10% coding. Coding is the easy part.

Josh

hmm ... thanks for the advice / warning. i had sort of naively hoped that it was possible to expect a program created for a given os to work on most computers using that os? i really don't want to start some kind of linux vs windows flame war, but isn't that part of the definition of an os? and if being open-source is such a requirement for a program being usable under linux, doesn't that sort of guarantee linux's failure as a mainstream desktop os?

anyway, i may be a bit naive, but i still expect that at least the executable, if not the plugin, should work on the _majority_ of linux systems. i guess we'll see when i release it (hopefully in the next couple of days). if it doesn't work on other systems then it doesn't work, and all i've lost is a couple of days configuring linux until i could finally compile a 'hello world' xmms input plugin, and half a day coding my own.

Hummm... I'm curious too about that.

(please, I don't want to tease any Linux user. See this as a question from a clueless Windows user)

Windows has very few compatibility problems. Programs written for DOS 6.22 still run fine on WinXP. Why doesn't Linux behaves the same way? Why are there so many compatibility issues with Linux binaries, even for x86 Linux architecture? I once wanted to host Linux binaries of FAAD at RareWares, but now it seems worthless.

There's 2 simple reasons really.

1. Linux supports an absolutely huge variety of different platforms. Windows mostly only supports x86. This alone leads to many compatability issues. Many different platforms don't react 100% similarly to identical code.

2. Many different revisions of software libraries on most platforms. One cause of this is related to the rapid development nature of open source (release early, release often) and the fact that not everyone can always be as up to date as others. The second part of this is kind of like #1 and is due to the fact that software libraries on different platforms may be slightly different from eachother due to architectural differences. Finally, not everyone has the same libraries because not everyone wants the same libraries. People on Open Source platforms like customizability, and because of that, you will see many different (and sometimes incompatible at a binary level) software configurations on individual (but relatively similar) machines.

You couple these 2 factors together, and it's pretty much impossible to provide a prebuilt set of binaries that will run on a very wide range of systems.

I don't really think this is the fault of the system though, rather more a consequence of choice. There's really no other way to do this and keep the advantages of an Open Source system (rapid bug fixes and peer review of code, rapid feature additions and improvements, portability, security, and customizability) unless we all want to run interpreted code (Java, Python, etc).. and we all know that even with those platforms, compatability is not absolutely 100% assured between architectures.

There's really an easy solution around it, and that's providing the source code. Some people don't like to do that, but that doesn't make the OS faulty, that just means that the people's developmental philosophy does not fit in with the needs of users on a very diversified platform. That's OK though.. it's their choice

I'm not sure that ability to run software written for one platform + OS on a different platform + OS is really a requirement for something to be considered an Operating System. Especially if you aren't even talking about software which makes use of the OS's API. In that case though, if you do use an OS API, then I would imagine that all platforms which run that OS (given that the API would be universal), would run that code.



I don't really see the relevance of this to the conversation at hand. The question isn't really whether or not Linux is going to be successful, it's whether or not La will be successful on Linux given it's current form

If it's not open source, it probably won't be nearly as successful as it could be. Given that, I think it's important to ask questions why it would be better to keep it closed than to keep it open, especially if you are actually serious about supporting it on the Linux platform.

A horde of nerds with very high opinions about themselves are using Linux. They believe they are way smarter than the people who released their linux distribution. So they recompile everything in order to optimise the system, thus breaking the distribution.

Frank Klemm has released some binaries for shorten, szip, optimfrog, mac, flac together with mppenc. They work just fine on a standard Red Hat system.

Edit: Ambiguity in first sentense.

I see flames coming on your direction.

And just when I thought Dibrom had brought the discussion to its logical conclusion. I predict this will now become one of those threads we have to mentally filter out of the top-10 for a while...

Posters, resist the urge to respond!

Josh

Unfortunately there exist a timing problem, when two people formulate a response at the same time. It took me a little time to write those lines, thus my reply came after Dibrom.

I do not intend to participate in a flaming linux discussion in this thread.

My statement is about some linux users, not about all. I have worked together with several clever linux people over the past four years. But I have also had my share of the too clever type.

An example: I've had six different people suggesting postfix over sendmail. Three of them could not set it up properly: a) mails go to wrong reciptient, B) server says relay ok, but mail never sent, c) bouncing mail.

As promised I've released the linux version now, so instead of debating whether a closed source release will work on many systems you can now download it instead and see. Here's the quote from the website:



So, as I say, please let me know if you find any problems or not. I'm no great Linux expert and I've only tested it on a grand total of 2 linux systems, but it seems to work fine .

I tried it in a chroot jail on one of my Redhat boxen (RH7.3, P3 500Mhz). Did a real quick test from 3 of the files from my normal suite:



la definitely compresses better, but is 17-20x slower encoding and 40x slower decoding (1.5x realtime).

Josh

Edit: P.S. How do you do a fixed-width font here? I thought the CODE tag used to work.

Did one more test, the bad news is it looks like la is not always lossless. I generated a 16-bit stereo WAV file of noise to work with:



So I tried the '-debug' option but it doesn't look like it'll be much help:



Josh

It worked in vB. Doesn't work in Invision. :/

thats worrying alright. damn ... i know that la's been tested and worked on pure noise samples before, so i'm guessing (hoping) its just a problem with the linux version, but i'll definately have a good look into whats going on here.

btw, the -debug option (which i didn't think was documented so i'm not sure how you discovered it, maybe just an educated guess?) helps if you use it when both encoding + decoding - then you can compare the 'budget crc' values and work out at which layer things are going wrong.




yeah, that about sums it up. la aims at a different end of the speed/compression ratio than flac basically.

If you have a place for it I can send you the WAV file (you can PM me with the location if you like, it's about 1.5 meg).



Heh, I was just poking around the binary. Kind of like taking apart an electronic toy you just got to see how it works... I'm guessing the runtime is significantly determined by the NN which is hard to really speed up? Just a guess.

Josh

thanks. i generated a 40mb noise file that broke it myself so i shouldn't need it ... btw, the windows version 0.3 seems broken too! (0.2 works at least). i guess it was kind of stupid of me to not test it on a noise file - i thought testing half a dozen or so albums with it was enough but obviously not.



well, don't read too much into the names my classes have ... but yeah, theres a form of neural net filter there which is a big determinant of the speed, but also the fact that there are 8 layers of filters makes it slow .

ok, the problems been fixed, and i"ve put fixed versions for windows+linux on the homepage. still compatible with the previous 0.3x versions.

so, please do your best to try and break it again .

Nice, seems that there are now at least 2 lossless codecs which use neural nets. Monkey's Audio and now LA. I'm wondering if LA would be as efficient if MA hadn't published its source.. And does that explain some other issues as well...

IIRC, Matt didn't allow his sources (including his neural net) to be used in LA.

But, of course, it's possible to take a look at Monkey's code and get a grasp of it's ideas, without using a coma of Matt's code.

Winamp seeking problem with large file is fixed!

Glad you noticed



that about sums it up. i did get a few ideas from matt's code which i'm really grateful for. although i'm not about to release my own code (and would appreciate it if people please stop questioning me on this), i try to be open with how it works, because i myself have benefited from understanding how mac works and the other authors have generally been helpful when i've asked.