1 - Thanks for the time and reply's
My question:
a) i was wondering if i can achieve a utility that takes in a MPC file and insert a wave header, like Riff Wave, so by that way i could insert it in VirtualDub and ofcourse in the movie, Is that possible???
b)There isn't still any tool to trim Mpc, to take out the silence from the start and end of the file, so we can save some HDD Space???
Regards,
Sniffer
If I'm not totally wrong, ChristianHJW praised his Matroska container to be able to use MPC audio..
If I'm not totally wrong, ChristianHJW praised his Matroska container to be able to use MPC audio..
You are wrong. First, i dont 'praise' stuff. Second, MPC will not find its way into matroska before SV8 is working, per decision by Frank Klemm himself ....
Second, MPC will not find its way into matroska before SV8 is working, per decision by Frank Klemm himself ....
BTW, did you hear anything from him about it in the last months?
Sorry, just curious. Maybe he's just taken a long vacation?
--
Ge Someone
Second, MPC will not find its way into matroska before SV8 is working, per decision by Frank Klemm himself ....
BTW, did you hear anything from him about it in the last months?
Sorry, just curious. Maybe he's just taken a long vacation?
--
Ge Someone
Seconded, i'd love to see some progress report on SV8. Matroska would also get a nice bonus from having mpc playable in their container format..
For highest Quality just keep the original compressed AC3 files. When working with 192kbps files I don't see much need for mpc.
Christian, who cares about Klemm? He even doesn't answer to your mails...this is not kind, and this means also that the developer has no more interests of his format. So my suggestion is to implement SV7 and ask this "german man" to release MPC sourcecode..at least there will be someone who will work about it.
For highest Quality just keep the original compressed AC3 files. When working with 192kbps files I don't see much need for mpc.
Average bitrate of mpc --standard is ~175 kbps for CD ripping. I've tried to encode a couple of DVD (movies) with the same setting, and bitrate failed at approx. ~135 kbps. It's interesting, even if input file is in AC3 stereo at 192 kbps. By downsampling a multichannel stream to stereo, reencoding to mpc is much more interesting.
When you said MPC failed at re-encoding, was it in the case that the encoded files sounded simply horrible?
Bitrate failed doesn't mean anything. Sorry. Bitrate fall, or bitrate drop... In other words: mpc --standard quality with an average bitrate close to a traditional CBR 128
Christian, who cares about Klemm? He even doesn't answer to your mails...this is not kind, and this means also that the developer has no more interests of his format. So my suggestion is to implement SV7 and ask this "german man" to release MPC sourcecode..at least there will be someone who will work about it.
We do care a lot about Frank's opinion a lot. He helped us with making the inital matroska framework, which evolved into EBML then.
On the other hand, i admit i dont understand why he doesnt answer at all about what his plans for MPC are, and if he has any at all. He must know that this silence from his side may discourage the users and the developers to care about MPC, even if today its still the best format.
To cut a long story short, we are discussing in the team if we maybe should change our opinion about MPC integration into MKV, even without SV8 being ready. The other option is, there is an SV8 alpha encoder already and we dont need the SV8 framing at all, as already long ago the decison was made to store MPC SV8 natively in matroska files, means stripped from its own native MPC framing.
I will try to talk to case about the usability of the alpha SV8 encoder. Maybe we just grab it, add the missing pieces ourselves and make a SV8 encoder writing MPC files in matroska container .....
Has this "alpha encoder" a good quality, comparable to the SV7 one?
Or does it suck?
Has this "alpha encoder" a good quality, comparable to the SV7 one?
Or does it suck?
As far as I know, there are changes so the '--xlevel' hack isn't required anymore, but most of the changes are to do with the container format and multichannel support. I have no idea how well advanced the code is though.
I do, however agree with the idea by Christian that we just take what Frank has started and continue it. There's really no excuse for him not even bothering to say 'yes' or 'no' to our requests so it looks like we have nothing left to lose.
I do, however agree with the idea by Christian that we just take what Frank has started and continue it.
we = who?
You must remember that there's only a handful of people here understanding enough about DSP that would be able to work on it.
we = who?
You must remember that there's only a handful of people here understanding enough about DSP that would be able to work on it.
Sorry, I meant us as in 'the community'. I'm not about to go hacking around in that source. I suspect most people worked that out themselves though.
I do, however agree with the idea by Christian that we just take what Frank has started and continue it. There's really no excuse for him not even bothering to say 'yes' or 'no' to our requests so it looks like we have nothing left to lose.
I still have the hope he might get motivated again by our constraints to move SV8 forward. Case was posting a message from him from September on IRC today that was more or less showing his frustration about the lack of support from other developers so far, and also that he has actually lost the believe in that its actually possible to work together on SV8.
Maybe we can prove him wrong and thus remotivate him to work on the encoder itself, which is where he can hardly be topped IMHO .....