Which is the best lossless codec?, Discussion thread Options

[Defsac]

When you encode with FLAC you can use "--replay-gain" option, so i guess that this is the reason for FLAC's support.

That was what I originally thought, that a "yes" indicated the encoder itself supported ReplayGain. Then I downloaded the latest WavPack binary and couldn't find any ReplayGain switches (there's no mention of ReplayGain in the documentation at all as far as I can tell), so in that case WavPack shouldn't be listed as supported. I also examined an output file I created using WavPack and was unable to find any ReplayGain data in the header or in tags.

I had a quick look to see if Monkey Audio can do this but couldnt find the info and gave up looking.

It can't.

Just because foobar can replaygain an audio file doesnt mean it nativly supports it?

What do you define as "native support"?

This post has been edited by Defsac: May 29 2005, 12:40

[Ariakis]

I'm not particularly familiar with the inclusion of ReplayGain in WavPack's specs, or the lack thereof in MAC's specs, but what I'm led to believe by the chart and what I've read around the forums is that "native support" for ReplayGain has to do with the format standard. If the official documentation or specifications include information on how specifically ReplayGain should be handled within the file and by a compliant encoder/decoder/whatever, then any "fully compliant" tool would have to support all the natively-defined operations for that format. If this is the case, then - for WavPack's example - the input plugins are more fully "compliant" than the CLI decoder with what's been said about the format specs, because they support ReplayGain for the format for whatever program in which they function.

[Defsac]

If the official documentation or specifications include information on how specifically ReplayGain should be handled within the file and by a compliant encoder/decoder/whatever, then any "fully compliant" tool would have to support all the natively-defined operations for that format.

As I said, the standard dictates an 8 bit field in the file's header. As far as I can tell, this is not present in WavPack, the documentation does not mention ReplayGain anywhere and there is no switches to either enable (if it's disabled by default) or disable (if it's enabled by default) ReplayGain in the encoder itself.

Edit: It is possible that ReplayGain is enabled by default and can not be disabled, but it's odd the documentation does not mention it.

This post has been edited by Defsac: May 29 2005, 12:55

[Ariakis]

As I said, the standard dictates an 8 bit field in the file's header. As far as I can tell, this is not present in WavPack, the documentation does not mention ReplayGain anywhere and there is no switches to either enable (if it's disabled by default) or disable (if it's enabled by default) ReplayGain in the encoder itself.

Indeed, sorry for missing your comment earlier about the 8-bit field in the header. It would seem that the table, WavPack's docs, and/or the information discussed so far are all in need of some revision.

[Defsac]

TTA, also listed as ReplayGain supported has a handy overview of it's header structure here, ReplayGain is not mentioned. Searching their site for "ReplayGain" and "Replay Gain" yields no results.

This post has been edited by Defsac: May 29 2005, 13:03

[kjoonlee]

Everything in this post (except for factual information) is my not-so-humble opinion.

The Replay Gain standard (on the website) is outdated. Ignore anything about the header.

The real 'de facto' RG standard, at the core, is an algorithm for calculating the gain values and peaks, and a method for making use of those values. How to implement the standard is up to software developers.

The only format (lossless or lossy) that really supports the RG standard through fileformat specs is Musepack. (edit: AFAIK. Correct me if I'm wrong, please.)

Except for MP3 and AAC, where the RG info may be used to alter the physical volume, other formats just use tagging to store RG info.

Just because flac.exe and metaflac.exe support reading and writing of RG info doesn't mean FLAC supports it natively and that support for RG is mandated.

---

If you define RG support as "supported through specs", FLAC should be mentioned as not supporting RG.

If you define RG support as "supported in reference implementation of tools", then FLAC should be mentioned as supporting RG. (edit: to a degree, at least.)

This post has been edited by kjoonlee: May 29 2005, 13:11

[rjamorim]

Yawn. This is becoming tiresome...

As you all know by now, I'm probably one of the least anal guys in this forum. I'm not inclined to worry about strict compliance to RG's original specs.

So where do I draw the line?

Here: if the developer himself coded replaygain support in the tools he releases with his format, that means the developer acknowledges it, so format supports replaygain. If only Peter Pawlovski cared to support replaygain for that format in his player, then the format doesn't support it.

It doesn't matter if the RG data is stored in a tag, a header, or the Windows registry!

So, for instance, Coalson released metaflac, and Bryant released player plugins supporting RG. Bryant also mentioned his plans to create a command line RG scanner for WV. OTOH, Ashland and Ghido never bothered to support it in any official or semi-official tools for their formats.

This post has been edited by rjamorim: May 29 2005, 15:49

[Defsac]

Yawn. This is becoming tiresome...

As you all know by now, I'm probably one of the least anal guys in this forum. I'm not inclined to worry about strict compliance to RG's original specs.

So where do I draw the line?

Here: if the developer himself coded replaygain support in the tools he releases with his format, that means the developer acknowledges it, so format supports replaygain. If only Peter Pawlovski cared to support replaygain for that format in his player, then the format doesn't support it.

It doesn't matter if the RG data is stored in a tag, a header, or the Windows registry!

So, for instance, Coalson released metaflac, and Bryant released player plugins supporting RG. Bryant also mentioned his plans to create a command line RG scanner for WV. OTOH, Ashland and Ghido never bothered to support it in any official or semi-official tools for their formats.

I agree that ReplayGain tools released with the codec should constitute replaygain support, through any tagging method. The only reason I mentioned tags vs. header fields is because Jan S. said supporting ReplayGain through tags was not the same as being supported by the format. I don't think releasing plugins with RG support should constitute RG support, or perhaps should be listed as "Partial" support like ALAC.

I also can't find any evidence of RG support in WavPack or TTA. There's no RG related switches and no mention of RG support in the documentation (the WavPack plugins support RG so by your definition it has RG support, but TTA doesn't mention RG at all).

This post has been edited by Defsac: May 31 2005, 07:19

[rjamorim]

I added streaming support to MAC since the changelog for the latest release seems to indicate streaming is supported.

Changed: Decoding engine better at handling corrupt streams / loss of internet connection while playing

http://www.monkeysaudio.com/versionhistory.html

Shameless lie.

I decided to test the lossless codecs WRT stream corruption.

My methodology: Encode a stream in each codec's default settings. Then take the encoded stream, open it in a Hex editor and replace a few bytes. Try to decode. If it decodes to the end (that is, skipping the corruption, and not exitting with an error when it reaches the corrupt frame), go to the next step, that is open the encoded stream in a hex editor again, and this time delete a handful of (5-6) bytes. Try to decode again.

The findings are very interesting.

Monkey's Audio
Replaced bytes: exits with error
Deleted bytes: didn't even try

OptimFrog
Replaced bytes: continues decoding and reports error at the end. Corrupt part was replaced with some seconds of silence
Deleted bytes: exits with error

WavPack
Replaced bytes: continues decoding and reports error at the end. Only sign of corruption was a tiny hiccup.
Deleted bytes: continues decoding and reports error at the end. Slightly larger hiccup.

FLAC
Replaced bytes: continues decoding when used the -F switch and reports error while decoding and at the end. Only sign of corruption was a hiccup.
Deleted bytes: continues decoding when used the -F switch and reports error while decoding and at the end. Only sign of corruption was a hiccup.

LPAC
Replaced bytes: continues decoding and reports error at the end. Only sign of corruption was a tiny hiccup.
Deleted bytes: Crashes rather ugly.


I plan to test other codecs soon. I'm putting "error handling" and "streaming" as "no" for Monkey's audio. What do you think about OFR and LPAC? Should they receive a "no" too, or bytes being deleted is just unlikely to happen?

Regards;

Roberto.

[snookerdoodle]

I plan to test other codecs soon. I'm putting "error handling" and "streaming" as "no" for Monkey's audio. What do you think about OFR and LPAC? Should they receive a "no" too, or bytes being deleted is just unlikely to happen?

Man, I never read this thread, thinking, "sheesh. how can you improve on lossless?" A lot of things here I hadn't thought of. So much for my omniscience award...

It certainly is possible for broadcast/multicast streaming methods to lose or corrupt data, even if you found that none currently in use do so.

It's nice of a decoder to not only handle the conditions, but to give a choice in how they're handled.

Mark

[Shade[ST]]

I plan to test other codecs soon. I'm putting "error handling" and "streaming" as "no" for Monkey's audio. What do you think about OFR and LPAC? Should they receive a "no" too, or bytes being deleted is just unlikely to happen?

Regards;

Roberto.

Personally, I think that lost packets due to CPU saturation is much more likely to happen than a stream being corrupt -- it's the most frequent problem I've had while streaming music (both server and client -- on a small DSL connection). Therefore, I consider it a greater issue.. maybe "streams with errors" should be a criterion?

[guruboolez]

(...) open it in a Hex editor and replace a few bytes. Try to decode. (...)
Monkey's Audio
Replaced bytes: exits with error
Deleted bytes: didn't even try

Could you also try with foobar2000 or maybe Winamp? I did this test once, and the playback went to the end, with only a little missing part and probably (I can't remember) a message error (fb2k console).

[rjamorim]

Could you also try with foobar2000 or maybe Winamp? I did this test once, and the playback went to the end, with only a little missing part and probably (I can't remember) a message error (fb2k console).

On Winamp: It's random. Sometimes, after the error till the end of the stream, there's only horrible white noise. On other occasions, just a small amount of silence and then it manages to resync.

On foobar2000 0.9beta, I get:

CODE

Decode error at 1:46.138 (Unsupported format or corrupted file):
D:\Figuras\Tests\Temp\Chariots.ape

[davechapman]

Not sure if this is the right place to announce this, but I've just added ALAC support to Rockbox. So the iriver H120/H140 (and other players in the future when new ports of Rockbox are finished) can also decode ALAC - it's not just the iPod any more.

And like all Rockbox codecs, it's gapless. .

Dave.

[user]

So, Flac and Wavpack are the most error robust codecs

This post has been edited by user: Sep 23 2005, 09:13

[Caroliano]

Some people think that an higher percentage means higher compression. So it would be interesting to add in someplace that "lower is better" for compression ratio. But I don't know where...

[earphiler]

FLAC is my favorite, because I can convert it to anything with dbpoweramp.

ALAC is pretty good, but its a proprietary Apple-only lock in format

APE has a bad name, and I hate the logo so I'm not really a fan.

WAV is good (not sure if this is considered lossless or just raw uncompressed) but the inability to store tags bothers me, of course it must be given some credit.

...And that's it what I've tried before.

FLAC is KING! and it encodes quickly

[Destroid]

About ReplayGain-

When dealing with lossless RG should be used in players and conversion tools. I think it is a bad idea to have lossless formats support RG natively, but it's not a entirely a banal feature.

While it is good to have RG I think that when dealing with lossless that it should be truly lossless. Although I am aware that the lossless audio data remains intact and native RG is stored for scale, there are no strict standards whether a player/tool enables RG by default or disables it by default.

From my perspective, which is using studio tracks losslessly encoded, I will stick with a format that does not upset the lossless scheme of things.

Thanks and happy holidays

[Martin H]

About ReplayGain-

When dealing with lossless RG should be used in players and conversion tools. I think it is a bad idea to have lossless formats support RG natively, but it's not a entirely a banal feature.

While it is good to have RG I think that when dealing with lossless that it should be truly lossless. Although I am aware that the lossless audio data remains intact and native RG is stored for scale, there are no strict standards whether a player/tool enables RG by default or disables it by default.

From my perspective, which is using studio tracks losslessly encoded, I will stick with a format that does not upset the lossless scheme of things.

Thanks and happy holidays

Sorry, but i really don't get your point... What exactly is bad with formats supporting replaygain natively in your oppenion ? And what do you mean with "I will stick with a format that does not upset the lossless scheme of things" ??? Formats like WavPack and FLAC which supports replaygain natively, dosen't have it enabled by default... I don't consider native replaygain as a bad thing at all, since it means that people wanting replaygain can use it natively without having to use external tools, but people who don't want to use it can just leave it alone... It's simply an added selectable feature, nothing more and nothing less... I could understand your point if it where the audio data itself that was changed, but since it's just a couple of tags added to the files with the gain values, which you are entirely free to enable or disable in players/tools, then i really don't see the problem... Native replaygain just means that the format itself contains code for analyzing the files for their respective replaygain values and for applaing the values as simple tags in the files, but it dosen't mean that it is enabled by default...

This post has been edited by Martin H: Dec 26 2005, 04:34

[Lyx]

I could write an unnecessarily long post, or make it short: the member which said that native RG-support would be against the principle of being lossless, doesn't know what he's talking about.

[Triza]

I could write an unnecessarily long post, or make it short: the member which said that native RG-support would be against the principle of being lossless, doesn't know what he's talking about.

Indeed.

I go further. Formats that do not support replaygain are pretty useless. After all I do not want to calculate the replaygain all the time. I want to do it only once and then I apply it or not as I like. If I do not apply it it will be truely lossless.

[d-b]

In many of the postings in this thread I see referals to a page (?) with the conclusions of the thread...but where is that posting/web page?

[Sebastian Mares]

This: http://wiki.hydrogenaudio.org/index.php?ti...less_comparison

[unfortunateson]

could somebody post the lossless comparison chart here? Ever since HA added the extra security measures to the wiki, it doesn't allow me to connect to it anymore.

[DARcode]

could somebody post the lossless comparison chart here?  Ever since HA added the extra security measures to the wiki, it doesn't allow me to connect to it anymore.

You really can't access this page via this link?
http://wiki.hydrogenaudio.org/index.php?ti...omparison_Table