INTERACT FORUM
More => Old Versions => Media Center 11 (Development Ended) => Topic started by: Raistlin2000 on April 06, 2003, 10:13:13 am
-
Since I'm not very experienced with coding since good old TP7-days, I would like to know if it is possible to modify an existing encoder-dll to support another encoder-exe.
I saw that all encoder contain an exe & a dll as interface between the exe & MC.
Is it possible for a complete stupid guy like me to modify the dll to support another encoder?
Thanks in advance
Raist
-
It appears that playback/decoding is done with the DLL's. For encoding, the exe's are used. What are you trying to do?
Note that I'm shooting from the hip, not knowing exactly how MJ/MC interfaces with the plug-ins.
Rx
-
Why Not Use The External Encoder Option.
This Is A Dll Plug-in where a user can interface with another encoder.
-
...and along with the King's settiments, tag wildcards on the encoder command line aren't necessary (this may be true only for common encoders such as oggenc, LAME, mppenc, and APE). If you use an uncommon encoder that the dll is not familiar with, then tagging may/will be problematic.
Rx
-
Till now I'm using external encoder with Xing, but this way I cannot use the "Rip'n'Encode" on-the-fly, decreasing performance.
Since Xing is the fastest encoder around, I could rip with 30x-speed using my Ricoh-Burner as reading-drive. (Tested this with Xing Audiocatalyst).
So the idea is to have a dll for Xing-Encoder, so I can forget about Audiocatalyst (offering only id3v1) & use Xing in conjunction with MC.
About the tagging: Isn't this done by MC after encoding or is this done by the encoder-exe?
Thanks for your replies,
I really hope to see a chance to use this super-fast-VBR-encoder with super-easy MC! 8)
Raist
-
Unless they've improved Xing recently, your sacrificing a lot of quality to gain speed as compared to LAME 3.90/3.92/3.94 (using the alt presets).
10-27
-
Maybe, but for pop-music I don't care, this style of music is not good enough for hearing differences.
And for classical music, I use only lossless compression.
So: Do you think that someone might help me in writing such a plugin for Xing?
Thanks for reply
Raist
-
If you could get JR to disclose how the tag values are inserted into the command line (ie wildcards), then you could use the external encoder option w/ the proper parameters to do the fill.
For instance, here's what I use in EAC:
--alt-preset standard --id3v2-only --pad-id3v2 --tt "%t" --ta "%a" --tl "%g" --ty %y --tc "EAC: Lame 3.92 @ alt pre std" --tn %n --tg "%m" %s %d
All the %'s are wildcards filled by EAC. If you could find the MC equivalent and if Xing supports command line tagging, then your set.
10-27
-
I don't think you have to anything to get the tags with the external encoder. I never have and it's been working fine.
As for the "rip and encode on the fly"... For most people, it's SLOWER, not faster.
You should also try using LAME with a quality setting of say -q 7 (lower quality = higher speed) and a high bit rate say 256 (higher bitrate = higher speed). You may be surprised at the speed. You can then do the "rip and encode simultaneously" if you really want.
-
Raist > Isn't this done by MC after encoding
Wow, could be. Try it. Post your results, I'm curious.
Remy...
-q 7? With LAME?
Aren't you thinking of Ogg(http://www.hydrogenaudio.org/style_images/1/icon12.gif) or MPC?
The -q factor will determine bitrates for either.
10-27
-
Unless I've completely lost my mind...
-q sets quality
0=best
9=least
The better the quality, the slower the encoder.
-b sets bitrate for cbr
The lower the bitrate, the slower the encoder (it has to work harder to compress more).
-
Remy,
OK, I see where your coming from on this. You are right. The alt presets set the -q value to 2 (0 & 1 are/were considered experimental...and seldom used). With the newer LAME's any of the alt presets will provide better quality (VBR in all cases except insane) at a given average bitrate then you could possibly achieve "rolling your own". But pinning them down to a specific bitrate undoes any advantage of them. Low bitrate CBR/ABR encoding should only be done for space or streaming bandwidth reasons. Regarding encoding speed, LAME is somewhat pokey no matter what the parameters are set to (but that's why it's the best MP3 encoder).
10-27
-
As for the "rip and encode on the fly"... For most people, it's SLOWER, not faster.
You should also try using LAME with a quality setting of say -q 7 (lower quality = higher speed) and a high bit rate say 256 (higher bitrate = higher speed). You may be surprised at the speed. You can then do the "rip and encode simultaneously" if you really want.
Well, for fast on-the-fly you have to use a burner-drive, their audio-extraction is much faster (even 40x with my Ricoh) & a super-fast-encoder, like Xing (30x). In fact, the ripping-speed decreases to 30x due to Xing, but WITHOUT on-the-fly it's one go with 40x & a second with 30x, so HOW CAN THIS BE FASTER THAN ON-THE-FLY?
About your lame-suggestions: I prefer VBR where LAME IS SUPER-SLOW!
It would be really nice to have a dll for the xing-exe, am I really alone with this idea?
Thanks
Raist