IPB

Welcome Guest ( Log In | Register )

13 Pages V  « < 6 7 8 9 10 > »   
Reply to this topicStart new topic
Which is the best lossless codec?, Discussion thread
Defsac
post May 29 2005, 12:27
Post #176





Group: Members
Posts: 347
Joined: 17-May 05
Member No.: 22107



QUOTE (dobz @ May 29 2005, 09:20 PM)
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.

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

QUOTE
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
Go to the top of the page
+Quote Post
Ariakis
post May 29 2005, 12:42
Post #177





Group: Members (Donating)
Posts: 145
Joined: 26-March 03
Member No.: 5677



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.
Go to the top of the page
+Quote Post
Defsac
post May 29 2005, 12:50
Post #178





Group: Members
Posts: 347
Joined: 17-May 05
Member No.: 22107



QUOTE (Ariakis @ May 29 2005, 09:42 PM)
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
Go to the top of the page
+Quote Post
Ariakis
post May 29 2005, 12:55
Post #179





Group: Members (Donating)
Posts: 145
Joined: 26-March 03
Member No.: 5677



QUOTE (Defsac @ May 29 2005, 06:50 AM)
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.
Go to the top of the page
+Quote Post
Defsac
post May 29 2005, 13:02
Post #180





Group: Members
Posts: 347
Joined: 17-May 05
Member No.: 22107



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
Go to the top of the page
+Quote Post
kjoonlee
post May 29 2005, 13:05
Post #181





Group: Members
Posts: 2526
Joined: 25-July 02
From: South Korea
Member No.: 2782



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


--------------------
http://blacksun.ivyro.net/vorbis/vorbisfaq.htm
Go to the top of the page
+Quote Post
rjamorim
post May 29 2005, 15:45
Post #182


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



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


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
Defsac
post May 31 2005, 07:18
Post #183





Group: Members
Posts: 347
Joined: 17-May 05
Member No.: 22107



QUOTE (rjamorim @ May 30 2005, 12:45 AM)
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
Go to the top of the page
+Quote Post
rjamorim
post Jul 28 2005, 22:32
Post #184


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE (Defsac @ May 17 2005, 11:44 AM)
I added streaming support to MAC since the changelog for the latest release seems to indicate streaming is supported.
QUOTE
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.


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
snookerdoodle
post Jul 28 2005, 22:46
Post #185





Group: Members
Posts: 120
Joined: 13-May 05
From: Albuquerque
Member No.: 22035



QUOTE (rjamorim @ Jul 28 2005, 03:32 PM)
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
Go to the top of the page
+Quote Post
Shade[ST]
post Jul 28 2005, 23:00
Post #186





Group: Members
Posts: 1189
Joined: 19-May 05
From: Montreal, Canada
Member No.: 22144



QUOTE (rjamorim @ Jul 28 2005, 03:32 PM)
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?
Go to the top of the page
+Quote Post
guruboolez
post Jul 29 2005, 01:32
Post #187





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



QUOTE (rjamorim @ Jul 28 2005, 10:32 PM)
(...) 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).
Go to the top of the page
+Quote Post
rjamorim
post Jul 29 2005, 19:53
Post #188


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE (guruboolez @ Jul 28 2005, 09:32 PM)
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


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
davechapman
post Sep 23 2005, 07:54
Post #189





Group: Members
Posts: 95
Joined: 28-April 04
Member No.: 13767



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. smile.gif.

Dave.
Go to the top of the page
+Quote Post
user
post Sep 23 2005, 09:13
Post #190





Group: Members
Posts: 873
Joined: 12-October 01
From: the great wide open
Member No.: 277



So, Flac and Wavpack are the most error robust codecs smile.gif

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


--------------------
www.High-Quality.ch.vu -- High Quality Audio Archiving Tutorials
Go to the top of the page
+Quote Post
Caroliano
post Dec 23 2005, 14:12
Post #191





Group: Members
Posts: 67
Joined: 21-December 05
Member No.: 26559



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...
Go to the top of the page
+Quote Post
earphiler
post Dec 24 2005, 21:05
Post #192





Group: Members
Posts: 168
Joined: 27-February 05
Member No.: 20208



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
Go to the top of the page
+Quote Post
Destroid
post Dec 25 2005, 19:09
Post #193





Group: Members
Posts: 550
Joined: 4-June 02
Member No.: 2220



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 smile.gif


--------------------
"Something bothering you, Mister Spock?"
Go to the top of the page
+Quote Post
Martin H
post Dec 26 2005, 04:28
Post #194





Group: Members
Posts: 857
Joined: 5-March 05
From: Denmark
Member No.: 20365



QUOTE (Destroid @ Dec 25 2005, 07:09 PM)
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 smile.gif
*

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
Go to the top of the page
+Quote Post
Lyx
post Dec 26 2005, 05:17
Post #195





Group: Members
Posts: 3353
Joined: 6-July 03
From: Sachsen (DE)
Member No.: 7609



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.


--------------------
I am arrogant and I can afford it because I deliver.
Go to the top of the page
+Quote Post
Triza
post Dec 26 2005, 05:43
Post #196





Group: Members
Posts: 367
Joined: 16-November 03
Member No.: 9867



QUOTE (Lyx @ Dec 25 2005, 08:17 PM)
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.
Go to the top of the page
+Quote Post
d-b
post Dec 26 2005, 11:06
Post #197





Group: Members
Posts: 34
Joined: 20-April 04
Member No.: 13609



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?
Go to the top of the page
+Quote Post
Sebastian Mares
post Dec 26 2005, 12:20
Post #198





Group: Members
Posts: 3629
Joined: 14-May 03
From: Bad Herrenalb
Member No.: 6613



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


--------------------
http://listening-tests.hydrogenaudio.org/sebastian/
Go to the top of the page
+Quote Post
unfortunateson
post Jan 31 2006, 22:58
Post #199





Group: Members
Posts: 294
Joined: 28-July 04
Member No.: 15838



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.
Go to the top of the page
+Quote Post
DARcode
post Feb 1 2006, 14:09
Post #200





Group: Members (Donating)
Posts: 681
Joined: 10-January 05
From: Italy
Member No.: 18968



QUOTE (unfortunateson @ Jan 31 2006, 11:58 PM)
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


--------------------
WavPack 4.70.0 -b384hx6cmv/qaac 2.41 -V 100
Go to the top of the page
+Quote Post

13 Pages V  « < 6 7 8 9 10 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 16th September 2014 - 23:28