gogo-no-coda Ver.3.11 was released.
http://member.nifty.ne.jp/~pen/free/gogo3/mct_gogo.htm (http://member.nifty.ne.jp/~pen/free/gogo3/mct_gogo.htm)
So GoGo is basically a tweaked Lame 3.88? Not much is said about the quality of this encoder, how good is it really? The quality of the new GoGo 3.11 is equivalent to what - Lame 3.88?
Also, my Japanese (or is it Korean?) is pretty rusty. Is it possible to make a simple homepage in English where you can read a bit about the history, progress and the developer(s) of GoGo..? Maybe that will draw some more attention to it.
can't read the page either. and are there any good frontends?
The english page I found is still with the old version, I downloaded the version from this site and compiled it, it´s based on lame 3.88 and extremly fast:
-q 0 18,84x realtime
-q 2 24,33x realtime
-q 5 38,21x realtime
-q 9 77,89x realtime
all with enabled psymodel at a Athlon Thunderbird 1333MHz
I don´t know how fast xing is, but this sounds much better (-b 128 -m j).
If you don´t trust me test yourself: http://l.b.oltmanns.bei.t-online.de/gogo311.zip (http://l.b.oltmanns.bei.t-online.de/gogo311.zip)
dll and exe. Compiled with ICL6 (/O3 /QaxiMKW /Qip /Qsox-).
So GoGo is basically a tweaked Lame 3.88? Not much is said about the quality of this encoder, how good is it really? The quality of the new GoGo 3.11 is equivalent to what - Lame 3.88?
From readme_e.txt
GOGO-no-coda ver. 3.11 for Windows, Linux and OS/2
updated Nov. 25, 2002
* ABSTRACT
This software is a mp3 encoder based on LAME3.88,
which is optimized for Enhanced 3D Now!/SSE/SSE2 and dual-CPUs.
Also, my Japanese (or is it Korean?) is pretty rusty. Is it possible to make a simple homepage in English where you can read a bit about the history, progress and the developer(s) of GoGo..? Maybe that will draw some more attention to it
Their English page (http://homepage1.nifty.com/herumi/gogo_e.html) is not updated yet...
However you could read babelfished (http://babelfish.altavista.com/urltrurl?url=member.nifty.ne.jp/~pen/free/gogo3/mct_gogo.htm&lp=ja_en&tt=url) their site.
can't read the page either. and are there any good frontends?
Try WAV2GOGO (http://home.wanadoo.nl/~w.speek/speek.htm).
Win32 binaries are available here: http://homepage.ntlworld.com/jfe1205/others.html (http://homepage.ntlworld.com/jfe1205/others.html)
Edit: BTW, if anyone downloads the Windows '.tar' file, rename it to '.tgz', otherwise you will have trouble decompressing it.
Win32 binaries are available here: http://homepage.ntlworld.com/jfe1205/others.html (http://homepage.ntlworld.com/jfe1205/others.html)
Which compiler-options do you use? My compile is 0,5x faster (but also twice as big).
Edit: BTW, if anyone downloads the Windows '.tar' file, rename it to '.tgz', otherwise you will have trouble decompressing it.
First I downloaded this lzh-archive, I could see the files, but I couldn´t uncompress it. The other archive could be decompressed by winrar without any problems.
Ah, thanx Harashin. I just couldn't seem to find the download link nor the English page! Must be tired today...
If I'm picky about the quality, can I use GoGo? (given that I wanna stick to mp3). I don't have time nor the equipment to perform any tests myself. I have a stack of CD's that I wanna convert to mp3 and I want to do it quickly. The file size should be around 190-200 kbps. I know Lame is pretty fast but I want Xing-speed and Lame quality. Possible? If so, which settings?
Which compiler-options do you use? My compile is 0,5x faster (but also twice as big).
Intel 6.0 with '03 /QaxiMK /Qsox- /Qip'. What are you using?
They are compressed using UPX: upx --best .....
Hi, I've tried to encode with this Command Line:
-v 2 -m j -vb 128 320 -q 2
Is this OK?
Can Gogo 3.11 reach neraly Lame APS Quality?
Greetz
Can Gogo 3.11 reach neraly Lame APS Quality?
no way i think!
Can Gogo 3.11 reach neraly Lame APS Quality?
no way i think!
But at the end of the day, if it is you who is going to listen to them and you're happy with the quality, it doesn't really matter what anyone else thinks! It won't be as good as LAME 3.90.2, etc, but it is probably better than the rest.
Intel 6.0 with '03 /QaxiMK /Qsox- /Qip'. What are you using?
They are compressed using UPX: upx --best .....
I´m using "/O3 /QaxiMKW /Qip /Qsox-" with ICL6, that´s nearly the same, I don´t have a Athlon-Thunderbird, so I cannot take advantage of the SSE2 optimization, so it must be randomly slower, because UPX decompresses the program at startup, so the start may take longer, but not the encoding.
I would like know if my compile is faster on Pentium 4 than yours because of the SSE2 optmizations.
Do you know if it´s better to use /QxiM for Athlon A/B/C & Pentium 2, /QxiMK for Pentium 3 & Athlon XP and /QxiMKW for Pentium 4? Because of Qx instead of Qax the optmizations has to be used, the programn won´t work without them. In HeadAC3he (ac3 transcoder) it is handled with the dlls like that.
I would like know if my compile is faster on Pentium 4 than yours because of the SSE2 optmizations.
I would guess no, because the speed critical sections of GoGo are pretty much all handwritten assembly. Plus, SSE2 isn't as cool as SSE because it only does 2 64-bit floats at a time (but it's still pretty cool).
Do you know if it´s better to use /QxiM for Athlon A/B/C & Pentium 2, /QxiMK for Pentium 3 & Athlon XP and /QxiMKW for Pentium 4? Because of Qx instead of Qax the optmizations has to be used, the programn won´t work without them. In HeadAC3he (ac3 transcoder) it is handled with the dlls like that.
Yes, using /Qx instead of /Qax produces
slightly faster code, but it'll crash on older processors! /Qx is especially faster on small functions that could be inlined, since /Qax prevents the compiler from inlining the vectorized function. Using DLLs compiled with /Qx kind of defeats the advantage of using /Qx because /Qax uses a dispatcher kind of thing to select the right version of each function, which is pretty much what using a DLL does. Using a DLL might be helpful for targeting more than one platform (like P-Pro, P-III, P-IV), because /Qax produces only specialized code and generic code (e.g. /QaxiMKW produces code that only runs on P-IVs and generic code for all x86s).
ICL7 is out now (just came out 11/21/2002) - haven't tried it yet (but I sure will). Also, in spring 2003, Microsoft will be releasing version 7.1 of their C++ compiler, which finally can do vectorization with SSE/SSE2 like ICL can - it's currently in beta testing.
Using a DLL might be helpful for targeting more than one platform (like P-Pro, P-III, P-IV), because /Qax produces only specialized code and generic code (e.g. /QaxiMKW produces code that only runs on P-IVs and generic code for all x86s).
So it would be better to use /QaxiM for Athlon, because with /QaxiMKW it wouldn´t use any optimization, because SSE and SSE2 is not supported and it only generates optimized (with SSE / SSE2) and non-optimized code? And /QxiM would be even better, but won´t run on processors without that optimizations? What would happen with /QxiM /QaxiMKW? Does it generate optmizated code (with MMX) and as alternative if avaible also SSE and SSE2?
I´ll try that.
ICL7 is out now (just came out 11/21/2002) - haven't tried it yet (but I sure will).
Do I need to a new license for that or will the old still work?
Now I finally found a bug in GoGo: It supports now Lame-Tags (-lametag on):
-MP3s with tags have terrible sync-errors and lots of other errors (mad-winamp-plug-in)
-It writes in the tag "LAME3.92"!
if you'll open the .dll in an hexa-editor and look at address 197835 (decimal) you'll see 'LAME3.92'.
I don't get this. So it's fast sure, but
1. it's actually LAME version 3.92 (THANKS DSPguru!), LAME 3.90.2 is a better, recommended version, not 3.92.
2. the newer "unofficial" release with tons of changes and improvements made by Takehiro produces files with MUCH better quality!! Why on earth would you want to encode files in lower quality when there is a much better alternative?
3. so WHAT if it's sooOO00oo fast, if Dibrom's builds' speeds aren't enough for you, i don't know what your problem is, i can understand a need for speed, but this is just useless..
I just don't understand all this GoGo thing.. It's inferior, period. It's like the Audi TT of encoders!! (if you know what i mean..)
1. it's actually LAME version 3.92 (THANKS DSPguru!), LAME 3.90.2 is a better, recommended version, not 3.92.
see the readme file: This software is a mp3 encoder based on LAME3.88,
which is optimized for Enhanced 3D Now!/SSE/SSE2 and dual-CPUs.
And in the history:
The following bug is fixed.
gogo happens to make mp3-data which can't be played by Windows Media
Player version 6.
supported LameTag output (-lametag on)
lame 3.92 is nowhere mentioned, I guess they just took the lametag-writer-source from lame3.92 and forgot to change the version-string. Look into the source-file vbrtag.c at the function CreateLameVBR, you´ll see:
'const char *szVersion = (const char *)"LAME3.92";'
I thought I could simply change that to "GOGO3.11", but encspot etc. finds the lametag by searching for "LAME", so that tag won´t be found anymore.
The tag has nothing to do with the real version, I can also write LAME3.96 in it, or even LAME5.27.
OK, my mistake, thanks for clearing that out.. Anyway, this means that it's even worse then..
3. so WHAT if it's sooOO00oo fast, if Dibrom's builds' speeds aren't enough for you, i don't know what your problem is, i can understand a need for speed, but this is just useless..
exactly my philosophy
Why do it fast when you can do it right...
For quite some time I have wondered if any part of GoGo could be ported to LAME for speed benefits. Speed boost would be a good way to market LAME and high fidelity MP3s, and for my PIII-500mhz - I'd like a speed boost for a change. Usually new revisions have slowed things down (for quality of course, but still..)
3. so WHAT if it's sooOO00oo fast, if Dibrom's builds' speeds aren't enough for you, i don't know what your problem is, i can understand a need for speed, but this is just useless..
I just don't understand all this GoGo thing.. It's inferior, period. It's like the Audi TT of encoders!! (if you know what i mean..)
What's wrong with having a faster encoder available? Maybe I'm in a rush and I just want to get my MPC album transcoded for a portable as quickly as possible... GoGo to the rescue!
GoGo's also ideal for people running music streaming servers. If you want to run multiple MP3 streams along with your Ogg streams (and whatever else), you might need a fast encoder like GoGo.
I'd never use GoGo for MP3 archiving (that's what the alt-presets are for!), but it's still nice to have it around and to see that it's being updated.
GoGo is my 2nd choice encoder, mainly when using my old machine(PII 233MMX/192 RAM).
To my ears it does a decent job.
I've found these simple ABR settings and both are fast like the "plain" 192 ~ 256 CBR:
-b 200 -a -q3
or
-b 250 -a -q2
I use plain stereo, because I believe GoGo doesnt carry the same JS improvements as the latest Lame compiles.
ABR settings around 180 kbits/s can also be used.
Last: Is it possible to create an GoGo filter for Cool Edit?(.flt)
LIF
What's wrong with having a faster encoder available? Maybe I'm in a rush and I just want to get my MPC album transcoded for a portable as quickly as possible... GoGo to the rescue!
How do I do that exactly? I've tried gogo with MPC2MP3 and it won't work (probably because MPC2MP3 is only for lame).
Is there an easier way to transcode MPC to MP3 using gogo?
So it would be better to use /QaxiM for Athlon, because with /QaxiMKW it wouldn´t use any optimization, because SSE and SSE2 is not supported and it only generates optimized (with SSE / SSE2) and non-optimized code? And /QxiM would be even better, but won´t run on processors without that optimizations? What would happen with /QxiM /QaxiMKW? Does it generate optmizated code (with MMX) and as alternative if avaible also SSE and SSE2?
I´ll try that.
Yep. /Qx switches mean that the binary will
require those instructions, and /Qax means that it will use them if available. You can combine /Qx and /Qax exactly like you mentioned. /Qx is usually faster, but it will
only run on newer processors that have those instructions. Athlon XPs have SSE, so /QxiMK would be good for them (actually /QxK implies /QxiMK so you can save yourself 2 bytes ).
ICL7 is out now (just came out 11/21/2002) - haven't tried it yet (but I sure will).
Do I need to a new license for that or will the old still work?
I think the old one will still work, but I'm not sure (well, my old evaluation one works - ICL7 is so good that I'm going to buy it for sure). I finally tried ICL7 and it pretty much blows VC++ .NET away when it comes to floating-point stuff. ICL7 seems to be a bit faster than ICL6.
A quick question about the lametag option.
With this feature activated, will encspot identify the file as lame 3.88 or some other version of Lame? Or will it identify itself as a gogo file?
If it says that the file is something it is not, that doesn't seem like much of a feature.
It will be identified as Lame 3.92 because Gogo identifies itself like this. This should be solved in new Gogo versions.
The file size should be around 190-200 kbps. I know Lame is pretty fast but I want Xing-speed and Lame quality. Possible? If so, which settings?
Now I don't know anything about Gogo, but if it's true that it's basically an assembler-tuned LAME v3.88, I would guess that it sounds quite similar to LAME v3.89 which I happen to know quite well, because I helped to integrate it into MP3Coder, a Win3x GUI for several DOS tools.
As this was the last version without the --alt-presets, you're stuck to the older presets, if you don't want to use your own command line options. A good overview of these presets and their equivalent parameters can be found with --preset help on the command line (sorry for widening everyone's screen solution in this thread now):
LAME version 3.89 (http://www.mp3dev.org/)
Presets are shortcuts for common or carefully tuned settings.
Several separate collections of preset profiles are available.
----------------------------------------------------------------
Basic- presets covering a wide span of qualities and bit rates
These presets may be combined with -v for VBR MP3s.
phone phon+ lw mw-eu mw-us sw fm voice radio tape hifi cd studio
===============================================================================================
--resample 8 11 11 11 16 11 32 24
--highpass 0.125 0.1
--lowpass 3.4 4 4 4 7.6 4 15 12 15 18 18
--lowpass-width 0 0 0 0 0 0 0 0 0 0.9 0.9
--noshort yes yes no no no no no yes no no no no no
-m -mm -mm -mm -mm -mm -mm -mj -mm -mj -mj -mj -ms -ms
-q -q5 -q5 -q5 -q5 -q5 -q5 -q3 -q5 -q3 -q3 -q5 -q5 -q5
-b 16 24 24 24 40 24 112 56 128 128 160 192 256
-- PLUS WITH -v -------------------------------------------------------------------------------
-V 6 4 3 3 3 3 3 4 3 3 2 1 0
-q -q5 -q5 -q5 -q5 -q5 -q5 -q3 -q5 -q3 -q3 -q2 -q2 -q2
-b 8 16 16 16 24 16 80 40 96 96 112 128 160
-B 24 32 56 56 112 56 256 112 256 256 320 320 320
-----------------------------------------------------------------------------------------------
EXAMPLES:
a) --preset fm
equals to: -mj -b112 --resample 32 --lowpass 15 --lowpass-width 0 -q3
b) -v --preset studio
equals to: -ms -V0 -b160 -B320 -q2
I've cleaned up this table for my own purposes, so it probably looks a bit different from yours, if Gogo will put out something similar at all.
As you can see, your aim is probably best achieved with --preset cd -v, so you would use a variable bitrate with a minimum of 128 and a maximum of 320 kbps, averaging somewhere at 192 kbps. This setting already sounded very good to me, but I did no comparisons with a newer LAME version and --alt-preset standard, because I lost interest in these high bitrates soon thereafter.
A little flaw with the high-range presets is also shown in this table: when
not using -v together with --preset hifi, cd or studio, the -q setting is defaulted to -q5 which is of course wrong, because it should rather be -q2, -q1 and -q0. But this is not the case when you combine these presets with a variable bitrate.
Sorry, but gogo do not offer presets.
Sorry, but gogo do not offer presets.
Gabriel is quite right, no presets in GoGo.
Sorry, but gogo do not offer presets.
Gabriel is quite right, no presets in GoGo.
So I guess Gogo doesn't have any presets?
OK, then he would have to use the command line parameters that make up the suggested CD preset with VBR: -V1 -b128 -B320 -k, or do they also have different names in Gogo?
Whoaaa... I really don't like to fiddle around with command lines. I tried the new gogo together with CDex and I played around with some of the few options available. q=0 and psychoacoustic-box checked. Dunno... I didn't think it was much faster than Lame really. The quality it provided was ok as far as I could tell. I'll probably stick with Lame :-)
And yes, EncSpot v1.0 lets you know when you have a file encoded with gogo. It says something like gogo >3.XX or >3.8X. Can't remember, I deleted the file.
BTW, a file encoded with FastEnc (vbr, not the buggy one) around 180-190 kbps, how good is it compared with Lame? I was baffled how fast it is.
q=0 and psychoacoustic-box checked. Dunno... I didn't think it was much faster than Lame really. The quality it provided was ok as far as I could tell. I'll probably stick with Lame :-)
As I already mentioned, I don't know Gogo, but I assume "q=0" probably means the same as in LAME
for CBR which is the best but also slowest setting concerning the psychoacoustic model in use. So it's no wonder that you noticed a slow-down with this setting.
Speaking of VBR settings in LAME, "q=0" can be misunderstood, because the command line would afford -V0 for the highest quality VBR setting, but the LAME display would both show "q=0" for this and also "q=2" for the psy model setting. I think this hasn't changed in newer LAME versions, but I'm too lazy to check it right now.
BTW, a file encoded with FastEnc (vbr, not the buggy one) around 180-190 kbps, how good is it compared with Lame? I was baffled how fast it is.
As far as I know, there haven't been any serious listening tests with these codecs at those high bitrates yet, so you would probably have to trust your own ears - which some people obviously just can't do...
Thanx. You're right, in the end, you just have to trust your ears. I actually think the FastEnc provides very good sounding files. I haven't decided which one to use, Fastenc or Lame. I don't think I'll give Gogo another try.
I made some speed tests with Gogo and Fastencc a while back. They may be somewhat relevent...
http://www.hydrogenaudio.org/forums/index....1592#entry15227 (http://www.hydrogenaudio.org/forums/index.php?act=ST&f=15&t=1592#entry15227)
Sorry, but gogo do not offer presets.
But why don't include the polyphase lowpass filter in GoGo?
It will help to increase the quality..
And maybe some automatic preset should be included too; this because a lot of people still use GoGo and simple presets like -192 or -160 will make easier the encoding.