Nero Oggplugin
- Thread starter demarc
- Start date
Not likely, although it might be a case of a license violation.
If Ahead has modified the free Xiph sourcecode, then they must also offer for free the modified sourcecode together with their plugin- else they violate the ogg license.
Most probably they broke something down (again), you must get used to it when using Nero.
If Ahead has modified the free Xiph sourcecode, then they must also offer for free the modified sourcecode together with their plugin- else they violate the ogg license.
Most probably they broke something down (again), you must get used to it when using Nero.
The nx---- plugins are not official, but are built to Ahead's SDK
(last compilation date, 1st April - so maybe they needed recompiling, to support a supposedly static API?).
I hope the chap does one to link to command line encoders with parameters, as that would allow a wide choice - just compare "Exact Audio Copy" - which can work with almost any codec you can source - with Ahead's self-serving plugin approach - they eventually bowed to criticism by opening it up, but that's too little, too late!
(last compilation date, 1st April - so maybe they needed recompiling, to support a supposedly static API?).
I hope the chap does one to link to command line encoders with parameters, as that would allow a wide choice - just compare "Exact Audio Copy" - which can work with almost any codec you can source - with Ahead's self-serving plugin approach - they eventually bowed to criticism by opening it up, but that's too little, too late!
THESE plugins don't support Exact Audio Copy, but since that program supports...
1. A pile of external command-line encoders (including custom settings)
2. All ACM based encoders
3. Some DLL based encoders (eg. LAME DLL version, there may be others)
- it's not exactly short of options...
Using a command line encoder might not be "pretty", but it sure as hell is versatile!
The only negative - not sure that EAC can decode and burn using the whole range of them.
1. A pile of external command-line encoders (including custom settings)
2. All ACM based encoders
3. Some DLL based encoders (eg. LAME DLL version, there may be others)
- it's not exactly short of options...
Using a command line encoder might not be "pretty", but it sure as hell is versatile!
The only negative - not sure that EAC can decode and burn using the whole range of them.
Just done an album(Led Zeppelin Coda) using EAC & the lame exe.
General settings as configured by the s/w
Lame Encode set to 192k
It took nearly an hour 2 copy CD then encode
I must be using wrong setting
But musicmatch does it in 5-10mins at almost all quality levels
But i will try it out with other encoders as i like EAC
BaNzI
General settings as configured by the s/w
Lame Encode set to 192k
It took nearly an hour 2 copy CD then encode
I must be using wrong setting
But musicmatch does it in 5-10mins at almost all quality levels
But i will try it out with other encoders as i like EAC
BaNzI
How much power do you have?
And which version / who's compile.
If I recall, hydrogenaudio forums have a sticky on "recommended compiles and settings"
There is even a DLL version which has been tweaked to map some settings to ALT-PRESETS.
Is it the encoder that's slow, or is it EAC being extra-cautious if it doesn't like the drive.
You're NOT using the obsolete "paranoid" mode, I presume - that is slow and not good for the drive
And which version / who's compile.
If I recall, hydrogenaudio forums have a sticky on "recommended compiles and settings"
There is even a DLL version which has been tweaked to map some settings to ALT-PRESETS.
Is it the encoder that's slow, or is it EAC being extra-cautious if it doesn't like the drive.
You're NOT using the obsolete "paranoid" mode, I presume - that is slow and not good for the drive