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: MPC encoding (Read 6574 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MPC encoding

yup...


what`s the story behind the "* standard"

BTW:
is there a * profile for CDex..

the * encodings are basicly:
--quality 7 --xlevel with provided logs..
220kbits according to recomended settings..
+ right tag.. order..

is this just for MPC format.. or
is it possible to "translate" this profile for
other formats..?

(somehow a daft question.. i know..)





MOD:* No links to or names of ripping groups please.

MPC encoding

Reply #1
yup...


is this to daft...

or is it possible to get a comment/answer..

after 86 views.. you should think so... 



MPC encoding

Reply #2
* is an MPC Ripping standard..
Of course you can rip with the *-Guide other Formats but then its not an * Rip

For informations and the * EAC Profile: '


MOD:* No links to or names of ripping groups please.
Blood & Cookies

MPC encoding

Reply #3
yup...


TnX.. for replye..

a. who started this.. and for what reason.

b. when i asked about "format translation"
my first thought was portable use..
with high quality ogg/mp3

(or perhaps there exist other "encoding standards"
for portables.. as far as i know.. mpc for P. is still no show..
or am i wrong))



MPC encoding

Reply #4
*

* is an Archive Quality Standard,

for Archiving music.


it is not fixed to MPC. The music matters !
This standard uses secure mode of EAC , ExactAudioCopy, to result to really safe digital extractions of CDs.
So CDex is not possible for using to backup your CDs in * quality standard.

MPC --quality 7 --xlevel is a minimum requirement.
One might use better quality, ie. q 7.5 --ms 15 xlevel, q 8 , q10, or lossless, like Monkeys Ape, or FLAC.

After you have backupped your original CDs in * on your PC (a good use is as jukebox !) or on CD-Rs, DVD-R's, HDDs, * albums offer you such a high quality, that you might transcode these albums to Ogg Vorbis (any quality setting) or mp3 @ 128 kbit or mp3 / lame @ --alt-preset standard/extreme/insane for use on your portable or even MP3-DVD-Player in living room.
Ogg and MP3 are best formats for portables, Ogg quality- (& size-) wise, mp3 for compatibility reasons.
So today, you might transcode your * albums to mp3,  some years later to Ogg, if you own then an Ogg-portable.
perhaps then already are mpc portables available in some variants, perhpas programmable mini-PCs/PDAs.

MPC encoding

Reply #5
yup...


@user...

1. of all... don`t shout at me..

and user. you have somehow..
answered my questions.. 

one thing remain though.. whos idea...?

bwt.  is EAC secure mode.. so secure..?

and another thing..
Quote
This standard uses secure mode of EAC , ExactAudioCopy, to result to really safe digital extractions of CDs.
So CDex is not possible for using to backup your CDs in * quality standard.


a. CDex full paranoia with evt. deglitch as companion..
b. such a statement as above... kinda force a user to use a spesific software..
for retriving sertain quality. is that a good idea..? 

(are you shure youre not slamming for Andre..)

MOD:* No links to or names of ripping groups please.

MPC encoding

Reply #6
Hi n68 !

sorry, if you should have misinterpreted the bold part of my text as shouting at you.

I did not talk directly to you, now I do. I know, that all, what  is written here in forum, is read by a lot people, so I try as often as possible, not to write in a secret language, which might be understood only by a minority of techies.

The bold part is not shouting at you, it is emphasizing the core of the answer. I think, the *-Guide tells itself, what it is. So I emphasized the location.

Yes, I answered your questions.



Now answers to your new questions:

EACs secure mode is really secure.

From my practical experience:

I live in a city with a nice public library which offers CDs and lately DVDs.
So I loan sometimes very scratched CDs, to test the extraction abilities of EAC and my 2 drives, a Toshiba and a Plextor.
Results:
So far, EAC's secure mode, * settings, has warned always for the suspicious positions. EAC, * settings, was always on the safe side, this means:
Never failed EAC, ie. if EAC reported: "no errors occured", * Musts fulfilled, ie matching checksums by test & copy,  then the rip had no audible glitches.
On the opposite, if EAC reported errors, suspicious postions, often there was still no audible glitch, but of course, if EAC reports erros, there are audible glitches sometimes.

Theoretical:

You find a lot answers to EACs modes here at this forum, and at EAC forum, at digital inn, find it by www.exactaudiocopy.de



Next questions:
well, I have read it long times ago, that CDex paranoia mode might result to comparable safety like EACs secure mode.

Sorry, I have never used Cdex ever, as I read here at HA and at digital inn, at came to the result, that EAC is the best, perfect tool for DAE. Maybe with CDex as second best, close to EAC, that was impression some time ago...
So I took EAC, and was convinced and never disappointed.

yeah, and later on, I found out, that EAC is used , too, by the high quality backup standards, ie. * and *.
Perhaps those standards use EAC, as it has the most advanced DAE technology and outputs logs, whith detailed information.



Well, nobody is "forced" to use a certain software, or a standard. One is free, to use a proposed standard.

well, I assume, if a standard is created, there have to be decisions, which way, method is used, otherwise, you would have no standardizing anymore.

A standard has always advantages, but disadvantages, perhaps, too.
pro: comparable quality, which is warranted by the standard.
con: a certain limited choice of possibilities, how to carry out, but otherwise: standard, or no standard, that is the question.




I am not getting money from Andre, I don't know him at all !
Only that he is a guy, who developed a perfect free- (postcard-) ware tool for DAE and a little more.
So, he doesn't get money either.

hmm, are you getting money from Cdex, or are you related to developers of CDex ?


MOD:* No links to or names of ripping groups please.

MPC encoding

Reply #7
yup...


lighten up dude... B)



MPC encoding

Reply #8
Open source zealots are highly common these days

MPC encoding

Reply #9


HA is not really the place to discuss ripping groups, their philosophies, or their ripping criteria.

And FWIW, something like this is hardly a "standard" in the sense most people on these boards would respect.

Take it somewhere else guys.

MPC encoding

Reply #10
yup...


  sorry....

found the link here.. in someones sign.
and wanted to check it out..

sounds somewhat "fishy" to me. 



MPC encoding

Reply #11
Quote
HA is not really the place to discuss ripping groups, their philosophies, or their ripping criteria...
...Take it somewhere else guys.

I'm interested in what people think of 'standards' like this so where do you suggest the discussion be taken to, I'd like to follow it to its new home?

MPC encoding

Reply #12
Quote
Quote
HA is not really the place to discuss ripping groups, their philosophies, or their ripping criteria...
...Take it somewhere else guys.

I'm interested in what people think of 'standards' like this so where do you suggest the discussion be taken to, I'd like to follow it to its new home?

I suggest you take it to wherever it is that the * ripping group people decide to congregate and discuss their "standard."

FWIW, I don't have a problem with people writing guides or suggesting certain ways to do things, but I do take issue with the overly dogmatic approach seen in these so-called "standards."  While there is some educational merit there, I think the approach is fundamentally flawed.  Education should be the primary goal, and from there the user should be able to make their own decisions.

Of course, nobody has to follow any of this stuff, but as you can see by statements such as "it's not a * rip then", that it's more about exclusivity and dogma than about educational merit.

Furthermore, the entire * philosophy is based on an illicit file trading group mentality (however thinly veiled behind a "ripping standard" it may be), which is far removed from the scope of these forums.

MPC encoding

Reply #13
Quote
FWIW, I don't have a problem with people writing guides or suggesting certain ways to do things, but I do take issue with the overly dogmatic approach seen in these so-called "standards."  While there is some educational merit there, I think the approach is fundamentally flawed.  Education should be the primary goal, and from there the user should be able to make their own decisions.

Of course, nobody has to follow any of this stuff, but as you can see by statements such as "it's not a * rip then", that it's more about exclusivity and dogma than about educational merit.

Well, there is some merit to deciding on some standards rather than always deciding on a case-by-case basis.  There's so many different ways to rip a CD, it'd take forever to judge everyone's preferred method, so it's easier to simple say "this way works, and anything else is not something we're going to consider."  Similar in some ways to the way we treat custom LAME command lines here -- if someone comes up with their own VBR command line, we respond with "just use --alt-preset standard/extreme/insane".

I do agree that the focus is significantly different than these forums though.

MPC encoding

Reply #14
Quote
Furthermore, the entire * philosophy is based on an illicit file trading group mentality (however thinly veiled behind a "ripping standard" it may be), which is far removed from the scope of these forums.


I have to agree here, I stumbled on this * thing by accident really and while I think it isn't bad from an information point of view (for newbies or anyone else) one of the first things that struck me was the potential for file trading, it seemed to me that this was what is was geared for. I mean it's pretty obvious, only people trading would be interested in verifying your files as *.

On the other hand this would appeal to a lot of people just for their own encoding purposes. It's a pretty good guide and a good starting point.

My view is try it (if you want) if you like it fine, just don't be afraid to tweak the settings for your own use.

But remember, it won't be a * file 


MOD:* No links to or names of ripping groups please.

MPC encoding

Reply #15
Quote
Well, there is some merit to deciding on some standards rather than always deciding on a case-by-case basis.

In that case, things should be presented as a "preferred method", not as some dogmatic standard, akin to something handed down from the "scene."

Quote
There's so many different ways to rip a CD, it'd take forever to judge everyone's preferred method, so it's easier to simple say "this way works, and anything else is not something we're going to consider."


Who is "we"?  In this case, it would be the * ripping group.  HA is not affiliated with them at all, and so this is another reason for me to emphasize this disassociation.

HA attempts to provide unbiased information and then present all alternatives (which is why we have so many different forums).  This is quite different then what you are proposing.

Quote
Similar in some ways to the way we treat custom LAME command lines here -- if someone comes up with their own VBR command line, we respond with "just use --alt-preset standard/extreme/insane".


This is a poor analogy.  A more correct one would to be recommend ripping a certain way, if you are using a certain program and have specific goals in mind (say, using EAC's secure mode if you are ripping with EAC and want secure rips).  There is no be all end all solution.  With LAME, the --alt-preset situation is not the way you portray it because, while it is the best approach to a certain problem, it is only the best for that specific case.  There are many other approach, most of which are better (AAC, MPC, Vorbis), and these are almost always discussed in conjunction with the --alt-presets.  Furthermore, there is no real "dogma" attached to it.  It is not pushed as a "standard" in the sense that these things are and it does not carry the cliche stigma of proprietery naming (think the "*" standard, and the "r3mix" standard, now think if the --alt-presets were called the "Dibrom" standard) or the elitest "club" mentality -- the --alt-presets are about providing people with tools, not telling them that if they want to be a part of something that they have to conform to some arbitrary standard.

Another problem with your analogy is that you don't take into account the ownership or control of the information.  The * "standard" is presumably controlled by a small group of people (similar to how the 192kbps no JS MP3 standard is dictated by a small group of so-called "council members" ).  The --alt-preset philosophy is owned by nobody, it's a public domain concept.  It has been this way through and through, from development, down to the code level, to public tuning and discussion, etc.

Finally, if this sort of "standard" were truly for educational merit, it would be more concerned with telling people how and possibly why they should do things for themselves or for the implicit worth of having this knowledge, not what they should do so that they can "conform to the standard".

MPC encoding

Reply #16
Yup, the whole */* so-called "standard" is IMHO completely missing the whole point of what Musepack is trying to achieve.

Look at it this way. I could go into a Porsche showroom, buy a new model, and never take it above 50kph. Sure, I'd be "safely" operating well within its safety parameters, but on the other hand,  it would never get the chance to show what it could really do. Likewise with the "insane", "braindead" MPC profiles.

Musepack as I understand it  is *designed* to be transparent using the *standard* profile. In a sense, it has a less complicated remit than MP3, Ogg Vorbis, AAC etc in that it does not have to compromise to fulfil a particular bitrate requirement. Perceptual transparency at the lowest possible bitrate.  Q.E.D.

If you have a problem with MPC --standard, post the clip/ABX results and Frank or whoever can deal with it. Personally, (having admittedly less than golden ears) this hasn't happened yet, and I'd be interested to see the clips where --standard fails and the * "standard" succeeds.


MOD:* No links to or names of ripping groups please.

MPC encoding

Reply #17
the fact that someone wrote a guide for eac/mpc and decided to call it the "* Standard" makes me laugh.  Its totally arbitrary, I hope too many people don't get led down the path that it is the only way to have acceptable digital audio.

And as far as trading goes, lets face it, if someone uses eac/mpc whatsoever it is preferable to most alternatives..  the -q7 cutoff is pretty anal.    I guess they are flexible in the sense that you can use -q10 though.  how considerate


MOD:* No links to or names of ripping groups please.

MPC encoding

Reply #18
* is retarded. All it does is make a lot of people waste a lot of good hard drive space.


MOD:* No links to or names of ripping groups please.

MPC encoding

Reply #19
Quote
* is retarded. All it does is make a lot of people waste a lot of good hard drive space.

I don't agree, although I don't use it's specs, I do agree with the overkill of q7 instead standard (at least when sharing with other people). If you have the original CD's then you should have no problem using standard on your pc (or whatever you feel comfortable with), however someone using only the mpc's would like them to be as transparent as possible (for example to burn them later onto audio cd or transcode to mp3 for portables) this might be good with q5 or q6 to your ears but some might feel a difference especially for some selected types of music, and since this "standard" is for generalized use it should take the worst case into consideration (I would have gone for q10 heh)

MPC encoding

Reply #20
*, *, Uber type "standards" have created methods of combining all the elements & creating high quality digital music, this may not have a place in HA but to those who truly love archiving & sharing high quality music these guides can be very interesting.

BTW About the Q5 vs Q7 issue, what about if you want to transcode? I know for a fact that both * & * do testing on problem samples with various Q settings once a new mpp enc is released so its not a roll of the dice.

MOD:* No links to or names of ripping groups please.

MPC encoding

Reply #21
Dibrom,
I respect your wish to not have the details of this standard discussed here. You run HA in a certain way and judging by the collection of people that choose to post here your approach is very successful. I also understand that having things such as the technical accuracy of the * standard validated here could be taken as an 'HA seal of approval' (if indeed it is accurate). That's obviously something you wouldn't want.

Can we discuss the value of standards in general?

Quote
...you don't take into account the ownership or control of the information. The * "standard" is presumably controlled by a small group of people (similar to how the 192kbps no JS MP3 standard is dictated by a small group of so-called "council members"  ). The --alt-preset philosophy is owned by nobody, it's a public domain concept.

I'm in two minds about this. On the one hand I can't see it making any difference as far as its technical credibility goes. I don't know the guys who came up with the standards listed above just as I don't know the many guys who worked to produce the --alt-preset settings. The number of people involved makes no odds to me.
However, I do agree with what I believe is your point here. Having public support for a standard means that support could be carried forward into other areas. The --alt-preset concept is more democratic than most others and so less open for abuse. Again it's not a technical point, but I do agree with it.

Quote
...things should be presented as a "preferred method", not as some dogmatic standard...
...Finally, if this sort of "standard" were truly for educational merit, it would be more concerned with telling people how and possibly why they should do things for themselves or for the implicit worth of having this knowledge, not what they should do so that they can "conform to the standard".

"Method" is a word I'd be happy with, it may even be a more accurate description. I do think that such a method should exist though.
File-sharing happens, CDs do get ripped to supply the sharing networks. I can't see how having a preferred method or not makes any difference to that at all. I can see, however, that CDs are not only ripped for file-sharing purposes.

This place is not just a meeting point where clever people come together to tell each other how clever they are - I've been hanging around here for a while, I know this. The general attitude here is a willingness to help people learn, why then is there some small amount of reluctance to encourage people to use that knowledge?

If I'm someone new to digital media and I want to make copies of my CDs for my use only in my office. I'm not interested in learning the different kinds of codec, I'm not interested in spending hours APXing various bitrates to determine what's transparent to me. All I want to do is get the best quality listening experience. If I came to HA and asked a full question saying what kind of music and how much space I have, I'd get plenty of helpful people suggesting different things (along with people telling me use fb2k  ). I'd probably get confused and just rip to mp3 "What, there are different kinds of mp3?" or wma since that's what most people seem to do. All the knowledge that HA holds would be wasted, in other words.

A simple and straight forward collection of methods (lossless, best lossy, compatible lossy, etc.) is totally in keeping with HA's principles as far as I can tell.


MOD:* No links to or names of ripping groups please.

 

MPC encoding

Reply #22
Quote
* is retarded. All it does is make a lot of people waste a lot of good hard drive space.

Great argument there. How about putting some actual information into your post? Blatant insults just look immature.
Musepack quality 7 does not waste a great deal of hard drive space. Its sizes are comparable to --alt-preset extreme and of much higher quality. Those that really care about their audio quality are indifferent to the amount of hard drive space their files are using. The best thing about Musepack at quality 7 is that it is the closest to lossless that you can get (in my knowledge) and takes up far less hard drive space.
AFAIK, Musepack wasn't created just for the "standard" setting as the alt presets were. I've never heard anyone (reputable) say that "Musepack at quality 7 is overkill". In my opinion, the extra safety introduced in quality 7 as compared to quality 5 is a huge advantage. I've seen a lot of results concerning the improvement in quality from quality 5 to quality 7.
Please, if you don't like something, spend the time to actually write something worth reading. I don't think many people on this board are here to flame, waste time or have pointless arguments. We would much prefer some discussion which actually involves some information and solid evidence.
Uh oh, you bwoke it.