What do you think?

Maybe the majority will vote for direct ogg support.

Evil gui * Evil gui * Evil gui ... etc

...and, well, why not open the EAC source ?

Perhaps the CPU usage is the deciding factor. I do not really know for sure, but perhaps it is more efficient for EAC to focus on extracting and error correction, then encode afterwards. This I am sure would only possibly be true for older machines.

On the Fly support is always cool… I’d like to see it as an option.

Why do you guys insist on creating these useless polls? It should be well known here that Andre doesn't read HydrogenAudio.

If you want on-the-fly compression in EAC, mail the author. Or post it at the proper forum.

honz318712:
The way EAC encodes .mp3 using LAME .dll is first to extract and encode afterwards (using default settings), so i guess it's not "true" on-the-fly

rjamorim:
I know it might not be "prober", but it seems that the author has no intention of replying to my e-mail request. Anyway I'm sure that somebody else are able to make this .dll for EAC

I don't believe in the power of on-the-fly encoding. It's very useful to normalize (I don't know what it makes for audio (not being exact copy etc?) but I like it) songs before compressing them.

manni:
There's no really difference between on-the-fly or not on-the-fly, and I don't see how normalizing could be easier this way? If you don't do it on-the-fly it will create a WAV PCM file, and on-the-fly the same file is created in the swap-file/memory and deleted after compression.

On the fly Vorbis encoding is already supported (kinda).

Use the following trick as a demo, just to see how useless it is.

1. Download the Ogg Vorbis cooledit filter from rarewares (don't forget libmmd.dll)
2. Put it in the same directory as the EAC executable and rename it to fht.flt
3. Now open EAC and play with the compression options.

Franciszek:
It works! Thanks!
You just forgot to mention these two additional easy steps:
Uncheck the box "Add Id Tag", on the"Waveform" screen (EAC, Compression Options)
All the files are wrongly created wich ".mp3" extension, so...just rename them to *.ogg.

How the franciszek "trick" works:

EAC natively supports the use of Frahunhofer MP3 plugin(filter) for CooEdit...(I didnt know this before)... and this file is named "fht.flt".

Good News:

Other Cool Edit plugins also should work with EAC.
I've tested the newest wavpack filter and no problems, except the need to replace the extensions from .mp3 to .wv. (very good speed in lossless mode, great job Bryant)
Bingo!

The DLLs already exist. But EAC needs to support them, and the only person who can fix that is Andre.






I would have thought that a member who has been with HA for nearly 1 1/2 years would know better than that.

Normalising before encoding serves no practical purpose at all. All it does is destroy the dynamics of the album (provided that not all files have the same peak value), and mess up track junctions on gapless (e.g. live) recordings. It does not at all make files equally loud as many assume.

Maybe it would be handy for people whom don't wish to fiddle with OggEnc.exe however there's no way shape or form I'd ever give up using Speek's Oggifier and Case's Tag.

No on-the-fly will ever replace what I prefer to do which is batch encoding of say 5+ albums one after the other, efficiency.

Hmm, being on-the-fly has not much to do with external compressor does it? I am not too much into using an external compressor if I could avoid it with a seamlessly integrating DLL instead. But I voted for non-on-the-fly because I am a paranoid and do not want to start encoding anything until the ripping is safely over.

Two probable reasons:

1. - Andre expects to license in the future some sort of EAC ripping engine SDK. If he opens the source, noone will want to buy it. (@ the GNU freaks: no, the GPL won't work. EAC's ripping engine is not only about code, it's about clever ideas to work around DAE limitations. People can copy these ideas without copying the actual code, therefore without breaking the GPL)

2. - Many drive vendors (like TEAC) release information and sample code about their drives only in NDA licenses. If Andre opens the code, he'll be breaking these licenses (considering he's using such information).

Regards;

Roberto.

I don't believe the question has much to do with a GUI interface; ...I, for one, use EAC because it's overkill for making sure the WAV is written bit-for-bit accurate. I, for one, put up with any extra time (if any), and find something else to do while my CD is being ripped.

AFAIK EAC is not suited for any kind of on-the-fly ripping (otherwise there probably would be an option to use stdin for cmd.line encoders) at all and it is not going to be implemented any time soon.

Regarding the OSS issue: André mentioned another reason for not opening the EAC source: Apparantly it's written in some uncommon/weird programming language (can't remember exactly) and opening the source would most likely not lead to any significant improvement in the development process.
If you want to work on / improve / hack an OSS DAE ripper take a look at cdparanoia (used by CDex in the form of CDRip.dll) or akrip (used by CD-DA X-Tractor and foo_cdda.dll).

dev0

The language is Modula II

Indeed, it's very unusual, but since it's a heavily structured Wirth language, porting to C shouldn't be terribly difficult.

Yey, Roberto! The mighty changing faces avatar returns! I missed it.

hehe. I finally moved it to a decent server.

Actually, Modula 3, IIRC. The Modula x language is very like Pascal, IIRC, but almost totally UNused outside academic institutions. Why they hell they couldn't teach people using a regular commercially applicable language is beyond me.

Because they want to teach people how to be programmers and computer scientists, not Visual Basic operators.

Same as any decent 'user' training will teach you how to word process, not how to operate Word Perfect for DOS 5.0 (It's amazing how many bad user training courses there were in the late 80s and early 90s )

Well, Andre himself posted it was Stony Brook Modula II
http://www.digital-inn.de/showthread.php?threadid=4819



Blah. I'd rather be taught a language that is widely used in the software industry environment (C, or even VB) than learning some language I would probably never use after I get my degree.

If you want to train programmers and CSs, C/C++ is much better than Pascal & variants, IMO. Because it's something you'll actually _use_ later.

Ah, and regarding your reply to John, C is very commercially applicable, not only VB. If it wasn't like that, every big compiler vendor (MS, Borland, Intel) wouldn't be supporting it.

I wouldn't. I'd rather be taught concepts. One of the most respected books in CS (Knuth) uses an invented machine language, precisely so the knowledge is provably independant from any one specific computer or language.

But this is getting WAY off-topic.

Why not be taught concepts on a widely used language?