Ok, I could make some encoding tests but I'm sure some of you already know the answer.
Since my previous PC died strangely, I have an old slow PC (K6 450Mhz, yes it still exists !). So, now I'm very interested by encoding speed, that's why i'm using 3.96.1 instead of the recommended one.
Still with the speed in mind (but without sacrifying quality), i was wondering wether the switch -nohist was helping accelerating the encoding speed.
Any answers appreciated.

Just encode a track with and without --nohist and you will see....

or as Beckenbauer says: "Schaun mer mal"

hummm very thoughtful but I'm french and had never learned german. Je ne comprends rien à ce que tu viens d'écrire.


No seriously, did you read my post ?

Sorry, maybe I was a bit childish. Of course I read it
et je comprends tout ce que tu viens d'écrire
It says "let's look" or so.

But to your question:
the speed increase depends on your graphics card.
On my laptop, encoding a .wav to .mp3 in a windowed DOS box with 3.97a10 shows these results:

-V2: 9.15x
-V2 --nohist: 9.29x

so here the speed increase would not be too great.

(this is what I meant with "just encode a track etc", the test only takes a few minutes)

Yes but NO. With my PC, the encoding speed, using "3.96.1 -preset 128", is 1.5X maximum when not doing anything on it, more often 1.2X.
If I want to make a decent measure of time I need to encode more than a few minutes which takes a lot of time for me. That's why I'd like to benefit from other users experience.
BTW thanks for your answer.


Nevertheless any speed increase is a victory for me !

Sometimes you can have an additionnal speed if you minimize the command prompt. This way, your computer do not have to refresh this window. (but this is for very slow computers)

If you want a few more speed, I'd suggest you to disable the replayGain computation.

Except that in this case, the poster has prevailed upon you to expend those few minutes, while he/she reaps the benefit. It may be just a small thing, but in principle it is true nonetheless.

This is a perfect example of an overall "let the other guy do it" kind of laziness, on the part of some posters, that this forum could well do without.

Regards,
Madrigal

here are two command lines I use (I grabbed them here at hydrogenaudio)

or


how can I disable the replayGain computation ? Sorry, i'm not very aware about this function.

OK, i found "--noreplaygain" in the lame help.

Even on an old P450, adequate test samples shouldn't take more than a few minutes to encode and compare.

Regards,
Madrigal

See ? Do-it-yourself still works.

Regards,
Madrigal

If speed is VERY important, you could try the FhG Pro ACM encoder that comes with MS WMP10 - it can provide you with fast encoded cbr mp3 with bitrates from 96 to 320 kbps. From MS, you will need l3codecp.acm and you will need to do some registry hacks to make it "visible" to other apps.
ACMenc 0.6 is a very useful CLI in conjunction with this codec, and it lets you use it as an external encoder from EAC or use for transcoding from foobar.

More info:
http://nyaochi.sakura.ne.jp/xoops/modules/...wares/tc_3.html
http://www.hydrogenaudio.org/forums/index....showtopic=26956

Wait wait wait. I never asked anyone to do the test for me. I wanted to know if somebody already knew the answer to my problem, if some people had experience about this switch.
This is not about laziness but about profiting from others past experiences and moreover this has been completed with a clever advice from gabriel (a_aa also but i want to keep Lame, thanks btw), exactly the kind of advice I wanted.


It is simply not the perfect example, not even an example, but you are the example of a suit of intention (sorry i don't know if it's the right expression in english). So, please Madrigal, before writing this kind of things, pay attention to what I wrote.

Your original question was as to whether use of the -nohist switch would increase encoding speed.

In order to "already know the answer" to that, in any meaningful way, somebody would have had to try it out using an old K6 450mHz computer. The logical candidate for such a test was you, hence Sunhillow's reply: "Just encode a track with and without --nohist and you will see..."

Your response to that was: "No seriously, did you read my post ?"

Now admittedly, you did not specifically ask Sunhillow to do the test for you, but the tone of your response sure seems to imply that you couldn't be bothered doing it yourself, a tone which was evident from the very opening of your original post: "Ok, I could make some encoding tests but..." (emphasis mine). That probably explains why Sunhillow went ahead and did it for you, even though his/her results on a presumably faster machine might not be relevant.

To make a long story short, I stand by what I wrote.
Hmmm ... in view of your response to Sunhillow above, that would make two of us now, who are allegedly not reading or paying attention to your posts. Does this tell you anything? Is this some kind of conspiracy against you? Or is it something else?

Regards,
Madrigal

Yep, I can vouch for that.
I too have a PII 450MHz.

@french dok
If u want more speed, try 3.97 alpha 10.
Though if u strictly want to encode in 128kbps (ABR?), I don't really know.
But its --preset fast standard is pretty much tested by guruboolez and gives good quality.
(though not enough tests to reassure that yet; but I trust guru's ears )

Thanks Madrigal,
apparently I already gave up the hope that kids might investigate something on their own.

@french doc, c'est souvent un avantage de comprendre plusieures langues, particulièrement des pays voisins. And for languages you don't understand, there are free services like Babelfish. They even translate chinese or russian to english.

Don't ask what Babelfish is, search for it

Well, i'm not going to write lines and lines, that would be useless (a funny jokes to make about my laziness, no ?). I just confirm that you lend me thoughts that I never had. My first post was precise enough ("but I'm sure some of you already know the answer").


Am I blamed because I chose spanish instead of german as third language ?


Thanks a lot Sunhillow. Do you answer kindly to somebody so as to be allowed to insult him after ?
_____________

I am really sorry that it generated all this conversation.
_____________

>> sh1leshk4
-As I am quite new in the world of quality encoding, I thought i would stay with the official lame realeases. I don't know many things about the alpha releases (I have to continue reading the forum!)
- 128AVR mp3s are for cds that i own and they're aimed to be played with a portable player. With street noises around me, 128 is enough, and my memory space is limited (512Mb).
- for the rest (keeping a lended cd on HD...) i'm using 3.96.1 APS. I will read all the stuffs about fast standard, it may be a good option for me, thank you.

The Gabriel advice about replaygain was very good, I now can reach 1.9X.

It is official; it's just that it's still in alpha.
(j/k; I know what u meant w/ 'official LAME releases'... )


Hmm...w/ street noises, I guess any LAME 128kbps encodes should do just fine, so u might wanna try 3.97 alpha 10.


It's been reported that --preset fast standard is better sounding than --preset standard in 3.97 alpha 10.
(though I don't have a set of golden ears to hear a difference; I'm trusting the tests around here)

IMO, u should try 3.97 alpha 10.
But, if u just want to 'play it safe', I guess 3.96.1's speed'd do just fine.

Btw, I thought APS is only on 3.90.3...?
By 'APS' in 3.96.1 did u mean --preset standard...?


Less processes, more speed.

Ok I will try 3.97 a10


Yes you're right I mean preset standard.


Oh yes I know, unfortunately 1.9X is the speed reached when nothing but the encoding program is running. With other processes, I easily go back to 0.6X

Thank you.

Possible new solution if you are ripping + encoding: postpone the time-consuming encoding to a period when you're ususally at sleep...

You could rip something like 15 CDs and start an encoding job on all these before you're getting to bed. Problem will be tags, of course, since wavs won't hold'em. You could use FLAC compression level 1 (which on a normal computer should give a speed at appr 40x) instead of LAME during the ripping. This would give you perfect files with tags for a nigthtime FLAC-to-LAME-mass-transcoding via foobar or dbPMC.

Basically, there is a possibility to change the way you use your tool, instead of changing the way your tools work. Don't know if you'll gain something on this, but it's an idea ... Using FLAC would of course require some HD-space available.

Err...in that case, don't you still have to wait and tag all of the FLACs...?
It'd only double his work then...

I don't think that's a good idea for me. My HD has only 20Gb of memory, and the ripping speed is also slow (between 1.2X and 2X in fast mode). It's also true that I don't want to rip all my CD collection, i'm not that in a hurry to let my PC On during night.

Nope. It would double the PCs work, not french_doks.
When the PC is doing job #2 (transcoding from FLAC to LAME mp3), it will do so unattended. He can sleep, go to a concert, do whatever he want when this is going on
Job #1 (ripping and lossless with tags) requires someone to insert new CDs when the previous has been ripped. This is the job that should be more effective.

My suggestion for making job #1 more effektive is only useful if FLAC compression level 0 is (much) faster than LAME abr 128. It should be, but I haven't tested it - thats why I said I didnt knew if it would gain him anything.

But since french dok lacks HD space, he is probably right when he consider this idea to be off-target for his requirements

Edit: Ooops - replaced "compression level 1" with "compression level 0", which actually is the fastest setting. (Can also use --fast)

Uh, yeah...and I guess that 'someone' is french dok himself.
In that case, what's the difference from encoding it straight to MP3s w/ LAME?
Besides, it requires more space and more time.

Efficient?
Yes, if french dok's not the one doing Job #1.

~justMy$0.02...

I'm sorry to be so unclear

Situation NOW: french dok is the one doing the CD changing, and he is waiting for a) rpipping process to finish, and he is waiting for b) the LAME-encoding+tagging to finish.

Situation MAYBE: french dok is the one doing the CD changing, and he is waiting for a) rpipping process to finish, and he is waiting for b) the FLAC-encoding+tagging to finish. If the FLAC encoding+tagging is much faster than LAME, he will wait less time, compared to Situation NOW. After creating lots of fast FLACs, he starts a mass transcoding, and do not wait/work anymore - he get out to have a beer with his mates... When he returns, happy & halfdrunk, the LAME mp3-files will be waiting for him on the computer.

See what I mean? The crucial point is to minimize encoding time during ripping, because encoding can be done unattended later. The fastest would be to avoid encoding at all during ripping, just put tags on the wavs - but thats not possible, is it? So the next best thing would be to use the fastest possible lossless encoding with tag support. Taginfo will be preserved during transcoding, of course.

Thanks for this idea but I am not compressing at an industrial scale .
I am only trying to get the best command line by using some switches such as --nohist and --noreplaygain.

Yes, I understand that - I'm not trying to convince you to use my idea - with your HD limitations it is utterly useless for you.
My last post was an effort to clearify what I meant, since I got the impression that someone misunderstood the crucial point.

I did som testing on Jane's Addiction - Three Days, duration 10:48:40:
Ripping with EAC secure mode: 52 sec
+ Encoding+tagging with LAME 3.90.3 abr 128 (ff123's and Hans'): 71 sec, or
+ Encoding+tagging with LAME 3.97a10 -v5 --vbr-new: 41 sec, or
+ Encoding+tagging with FLAC --fast: 8 sec

So basically, if you plan to start ripping "industrial scale" (when you get yourself a decent PC), I would have considered to use FLAC --fast in conjunction with the ripping process, and do the mass transcoding to whatever you want later on... (No big news from me here, as you can see...)

Me?

I did understand the 'crucial point' of yours; I was just stating that it's not feasible (at the moment) for french dok.
Now I have the impression you didn't really get my 'crucial point'.

Well, anyway, now that french dok has got the answers he needed, let us pray his K6 won't blow up on the 10th CD.

~justKidding...

I hope that will be ok because the buying of a new PC cannot be thought for the moment !