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: gogo 3.13a release (Read 14001 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

gogo 3.13a release

Reply #25 –
Hi!
I'd like to make gogo work with Audiograbber. Audiograbber can use external encoders "as internal" if the encoder supports stdin. gogo.exe does ... BUT! Audiograbber writes the audiostream in raw (44kHz, 16bit signed or unsigned) format and gogo waits for a wav format. In the older Gogo versions (2.39b) there was an option to specify the input format, but in these old versions the pipe function doesn't work:). I looked into the gogo 3.13 source, and I saw that if the input filename is 'something.raw' gogo will know, that this is a raw file. But in pipe-mode the input filename must be 'stdin'. I compiled Gogo with DJGPP for DOS, but the pipe funtion in my version doesn't work. What's a pity! So if you can programming, PLZ compile a 3.13 version which works with Audiograbber.
I've tryed a lot of CD-rippers (which officially support gogo.dll), but those were much slower than Audiograbber (I don't know why, tested with the same lame_enc.dll with the same(?) options): Bonkenc, EAC, CDex ...
So this solution would be the nicest.
Or if you can suggest an fast, up-to-date, highly configurable, modular(!) CD-ripper...
THX

gogo 3.13a release

Reply #26 –
I know it's not really answer your question combo, but there's an old application called "audiogogo" that is a ripper and frontend for gogo. I had an old version that was using some 2.xx version of gogo, I just put the 3.13 version gogo.dll (downloaded from rarewares) into the audio gogo folder and it's working ok.

Has anyone done any tests on the quality of gogo lately. I used the use an old version that came with audiogogo quite a bit before I started using lame.

BTW. I notice that the alpha12 version of Lame4 that I'm testing is every bit as fast as this new gogo when both in vbr mode. Maybe Lame 4 will make gogo redundant, when it's eventually released other than alpha that is.

gogo 3.13a release

Reply #27 –
THX for your reply.

I know and use AudioGogo with the updated gogo.dll. AudioGogo is as fast Audiograbber but unfortunately quite outdated and doesn't support lame.dll. You know, if I grab my favourite songs, I use a good encoder (lame or ogg ...). But I use a fast encoder in other cases (e.g. rip a whole CD to my brother:)  because I've a slow k6-2 machine.
I hoped that there is a _fast_ CD-ripper which supports both gogo and lame, but for example CDex is much slower than AudioGogo while encoding with gogo and much slower than Audiograbber while encoding with lame on my machine. (With the same params, but we can't set EXACTLY: only kb/s...).
And unfortunately my question is not actual now, because I've tested Audiograbber with lame.exe (pipe-mode) and that was twice slower than with lame_enc.dll. Probably this would happen with gogo.exe too. So I must use 2 CD-rippers until I find the best one. (The ideal solutions would be: AudioGogo with lame support OR gogo.dll should be lame_enc.dll compatible)

lame4: I'm look forward to this version; I hope you've tested with wav->mp3 encoding not with CD-grabbing. Because as I think on a fast machine the speed of the on-the-fly CD->MP3 grabbing only depends on the CD-reader's speed, if your CD-ROM drive uses DMA (and both encoders' speed is faster then CD-reading speed). I'm not sure on this, but if this is true, everyone with P4-2GHz(...) machine should grab CD with a high quality encoder (with high quality settings).
I'll give lame4 a try anyway. (Its dll is compatible with 3.xx's dll, isn't it?)

THX again for your reply.

gogo 3.13a release

Reply #28 –
Quote
lame4: I'm look forward to this version; I hope you've tested with wav->mp3 encoding not with CD-grabbing. Because as I think on a fast machine the speed of the on-the-fly CD->MP3 grabbing only depends on the CD-reader's speed, if your CD-ROM drive uses DMA (and both encoders' speed is faster then CD-reading speed). I'm not sure on this, but if this is true, everyone with P4-2GHz(...) machine should grab CD with a high quality encoder (with high quality settings).
I'll give lame4 a try anyway. (Its dll is compatible with 3.xx's dll, isn't it?)

THX again for your reply.
[a href="index.php?act=findpost&pid=266591"][{POST_SNAPBACK}][/a]


Yeah I encoded wav->mp3 to test the speed of both gogo and lame4, I used the VBR -v4 in each case. Both lame4 and gogo can hit speeds around 32x on my AthlonXP so the CD's DAE speed is mostly going to be the limiting factor with these fast encoders.

Unfortunately I dont know if lame4 has a dll version compiled yet, I was only able to download the exe. Anyway it's still in alpha so you'd probably be safer with gogo.