Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: La 0.3 Released (Read 20872 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

La 0.3 Released

Quote
* Change Log - Changes since version 0.2

Compression has been improved around 0.3% (i.e. compressed files average around
0.6% smaller). Speed is approximately the same as the previous version.

The file format is of course different due to the above compression changes,
however La 0.3 will still play files from La 0.2.

A couple of bugs in the winamp plugin have been fixed, the major one was that
it previously assumed all files where 44khz and thus played (for example) 22khz
files at double speed.

Handles .wav files with more complicated headers better.


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

La 0.3 Released

Reply #1 –
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.

La 0.3 Released

Reply #2 –
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

La 0.3 Released

Reply #3 –
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.

La 0.3 Released

Reply #4 –
Quote
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

La 0.3 Released

Reply #5 –
Quote
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:

I found a tracklist here:
http://www.macs.demon.nl/anouk/special/ano...-platinaed.html

Hans

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.
Diocletian

Time Travel Agency
Book a journey to the Diocletian Palace. Not today!

La 0.3 Released

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

La 0.3 Released

Reply #7 –
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.

La 0.3 Released

Reply #8 –
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...
Juha Laaksonheimo

La 0.3 Released

Reply #9 –
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.

La 0.3 Released

Reply #10 –
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.

La 0.3 Released

Reply #11 –
Quote
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.


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.

La 0.3 Released

Reply #12 –
Quote
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?
Juha Laaksonheimo

La 0.3 Released

Reply #13 –
Quote
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.

La 0.3 Released

Reply #14 –
Quote
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.

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..
Juha Laaksonheimo

La 0.3 Released

Reply #15 –
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

La 0.3 Released

Reply #16 –
Quote
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.


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).

La 0.3 Released

Reply #17 –
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.
 

La 0.3 Released

Reply #18 –
Quote
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?

La 0.3 Released

Reply #19 –
Quote
Quote
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.

La 0.3 Released

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


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.

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

La 0.3 Released

Reply #21 –
Quote
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.


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.

La 0.3 Released

Reply #22 –
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.

La 0.3 Released

Reply #23 –
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

La 0.3 Released

Reply #24 –
Quote
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?


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.

Quote
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?


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.