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: Is there any reason to switch from WavPack to APE? (Read 18349 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Is there any reason to switch from WavPack to APE?

Reply #25 –
MA doesn't have native RG support. It is up to the player to implement it (FB2K or similar). Matt even said this somewhere here or in the MA forum.

Is there any reason to switch from WavPack to APE?

Reply #26 –
Quote from: shadowking on
MA doesn't have native RG support. It is up to the player to implement it (FB2K or similar). Matt even said this somewhere here or in the MA forum.


That's the whole point. If the author himself claims the format doesn't officially support ReplayGain, support coming out of player developers' initiative won't be enough.

Is there any reason to switch from WavPack to APE?

Reply #27 –
FWIW, J. River's Media Center also supports RG with APE. Of course Matt Ashland is one of the lead Media Center devs though 

Is there any reason to switch from WavPack to APE?

Reply #28 –
Quote from: rjamorim on
Zero tolerance is idiotic no matter how you look at it. WavPack can also be considered "intolerant" since the command line decoder always warns about stream errors. But then it keeps decoding, so that you lose the least data. In Monkey's Audio case, besides outputting an error - not a warning - you lose lots of data.

In this case the first data loss has already happened before decoding. MA prevents this data loss from spreading so that the problem can be fixed before continuing. (I don't usually use command line decoders).

But, please, I don't really want to start a debate on this. Everyone can make his or her own format choices that are based on the information that is available in HA.

I may start using some other lossless format today, but without a very good reason I am not going to convert my Monkey's Audio archives to another format. I have ripped about 2000 CDs in Monkeys Audio disc image + cue + APL format and I have two backup archives. That makes a lot of HDs full of that stuff.

I would like to add that in my opinion the OP has no reason to convert perfectly good WavPack files to Monkey's Audio. The storage space savings are marginal, as already said.


Quote
The difference between Monkey's Audio and WavPack, in this aspect, is that David Bryant officially endorses ReplayGain and he implemented it in the official tools. I think it's also mentioned in the documentation. Ashland never endorsed ReplayGain, it took Peter Pawlowski to hack it into the format. The outcome is that foobar is pretty much the only tool supporting replaygain on Monkey's. The winamp plugin doesn't support, the Audition filter doesn't support, the official decoder doesn't support, the XMMS plugin doesn't support, shntool doesn't support... that's why Wikipedia and the HA wiki list it as lacking RG support (well, someone recently messed - again - the HA wiki comparison, but I fixed it already)

If foobar support alone was enough, pretty much every codec could be considered RG-aware.

Yes, I know these things.

Personally I have used replay gain with Monkey's Audio files since Media Jukebox 8 was introduced in early 2002. This was before foobar2000 and most of the replay gain enabled plugins for other programs & formats were available. The MJ8 beta in late 2001 was one of the first player programs (if not the first) that had a replay gain analyzer and a playback correction system. Matt (who works for J. River) followed strictly the proposed standard and J. River uses the original 83 dB reference value. In their newer program, Media Center, they introduced a clever album gain system that calculates database based album gain values on the fly.

Perhaps unfortunately J. River has not followed what the rest of the world (excluding of course the big guys like WMP, iTunes and Real) has done with Replay Gain since then. They still use their own replay gain tags and the originally proposed reference value.

Is there any reason to switch from WavPack to APE?

Reply #29 –
@rjamorim : Thank you for your clarification.

I think I will switch to WavPack in the future, when its speed and/or compression will be improved. 
Opus 96 kb/s (Android) / Vorbis -q5 (PC) / WavPack -hhx6m (Archive)

Is there any reason to switch from WavPack to APE?

Reply #30 –
Quote from: Alex B on
In this case the first data loss has already happened before decoding. MA prevents this data loss from spreading so that the problem can be fixed before continuing. (I don't usually use command line decoders).


It is still unjustifiable to have an unforgiving decoder. You said you use Monkey's for archiving. The purpose of archiving is to save data for future usage, and if part of the data is unrecoverable, you should still be able to recover as much as possible.

If you care so much about integrity, it's your job to keep a close eye when the data is being recovered. Even with Monkey's Audio: if you decode an APE stream corrupted at the last few seconds, you probably won't notice the corruption anyway, and it might spread...

Oh, BTW, I think foobar also reports corrupt streams through its log console.

Quote
But, please, I don't really want to start a debate on this.


Too bad, this thread was becoimg interesting. But I understand your position...

Quote
Everyone can make his or her own format choices that are based on the information that is available in HA.


And why not increase the knowledge pool at HA adding valuable information to this very thread?

Quote from: dutch109 on
@rjamorim : Thank you for your clarification.

I think I will switch to WavPack in the future, when its speed and/or compression will be improved. 


That is not very likely to happen. Maybe speed will increase a little if David or someone else works on assembly optimizations, but compression probably already reached its sweet spot. I believe that, from now on, David will focus more on format features and improving software and hardware support.

Is there any reason to switch from WavPack to APE?

Reply #31 –
Quote from: rjamorim on
Quote
Everyone can make his or her own format choices that are based on the information that is available in HA.

And why not increase the knowledge pool at HA adding valuable information to this very thread?

I appreciate knowing this.

I have no use for a format that will continue decoding through errors even if it gives you a heads-up.

At least flac gives you the option.

Thanks for filling me in.

Is there any reason to switch from WavPack to APE?

Reply #32 –
thanks for all the input guys.  Big help.  I am purchasing two seagate 320 gb hard drives with 5 year warrenties.  One for use with raid 1 in mind.  i will keep the wavpack files for now as i don't think space is an issue at the moment. 

Where does foobar report an error during decoding?