INTERACT FORUM

Hi
Yup, They are virtual drives, provided by Daemon Tools. It just means i don't have to burn cd's for stuff which is packed in *.bin, *.cue or *.iso files which i'm only going to watch once. It's not so much the money thing, it's just alot quicker and quieter this way.
I can't check out the filter thing till i get home tonight, i have been playing with my firewall and it appears i have screwed the remote access!
cheers for the input
mark

Good find, gamer!

Pinnacle, a name to drive fear into the hearts of man everywhere..... Do you think someone could explain the concept of bug fixing to them?! I have a pinnacle pctv card do you think it might be that? I will investigate further this evening....
This still doesn't explain the massive difference between version 10 and 11, i had all this stuff installed way before i even had version 10.
getting closer though....
cheers
mark

Ok, i feel we got a it side-tracked here. Virtual drives are not the problem, i have uninstalled Daemon Tools so i'm back to a normal-ish setup. MC11 is now managing to rip at 1.4x (a slight improvement i admit) but still nothing like i got with version 10.
Checking the task manager shows Lame.exe is really hogging the resources, any chance V11 is using an experimental version of lame?

Ripping and encoding are technically two different stages in the process. The next procedure may help in finding out where the problem lies:

1. Rip and encode to Wave. What is the time?

2. Convert the Wave files (from step 1.) to MP3. What is the time?

3. Rip and encode to MP3. What is the time?

I have always kept the "Rip and encode simultaneously" option disabled without speed problems. I don't know if that makes any difference.

The LAME 3.96.1 encoder, which is used with MC11 encodes generally much faster than the previously used LAME 3.93 unless JRiver changed something critical.
(That may depend on the settings used and the new internal mappings in LAME 3.96.1.)

milknkukis,

Normally LAME.EXE uses all available CPU time. MC11 uses the current stable version. Though, I have noticed one strange thing: the LAME.EXE in MC11 is 740 KB, but the separate 3.96.1 encoder is only 184 KB.

sirshambling,

You can get the separate LAME 3.96.1 encoder from here: www.rarewares.org. You can use it as an external encoder with MC10/11.

Thanks Alex - most helpful.

I've done a test with a single 5.26 minute track using the same settings (secure, max) on the same DVD drive for both MC 10 and MC11 as you suggested. The eventual files were MP3 128 CBR files using the encoder that comes with each of the programs.

The intersting (to me at least) results are:-

MC11

Rip and Encode simultaneoulsy - 262 seconds
Rip only                                     - 43 seconds
Encode only                              - 202 seconds

MC 10

Rip and Encode simultaneously - 67 seconds
Rip only                                     - 41 seconds
Encode only                              - 29 seconds

The clear difference is the encoding for MC11 which is some 8 to 9 x slower than MC10. This bears out my subjective experience when encoding files I've imported as WAV and converted within MC11.

You say there's a different encoder with MC11 - my (untutored) view is that this is configured way worse than the one in MC10.

Can you give me some instructions on how I can

a) find the MC10 encoder
b) use it in MC11

Unless the good people at JRiver would care to look at this - John G is this your bag?

TIA. John.

... MP3 128 CBR files using the encoder that comes with each of the programs.

128 kbps - I haven't encoded anything so low for a long time. But now I did (Quickly, because I don't have much time now. Some guests are coming soon...).

Test track: APE 5 min 20 sec
Converting to 128 kbps MP3, advanced setting "normal"

MC11 with default encoder (LAME 3.96.1) - about 35 s.
MC10 with default encoder (LAME 3.93) - about 27 s.
MC10 with LAME 3.96.1 (I changed the "lame.exe" file in the plugins folder) - about 35 s.

No big differences here. I think that LAME 396.1 is a bit slower because it uses more advanced CBR presets by default even if the user doesn't define a custom string. The quality should be better, especially at 128 kbps. VBR encoding (with --preset settings) is faster with v. 3.96.1.

However, something must be wrong, because you got so big differences.

I have a P4, 2.8 GHz, Hyperthreading on, XP SP1.
Hyperthreading actually makes encoding slower, because LAME uses only one of the virtual prosessors. The good point is that the system stays more responsive.

You can just replace the LAME.EXE file in the plugins folder with a version you like, but I don't know if there is extra code included with the MC11 encoder and where/how it is used. The size difference is big....

sirshambling, you wrote in MC 11 bug thread:

The MP3 encoder now loads fine - but I'm still getting very slow rip/encode and file conversion speeds using the default encoder as opposed to an external LAME one sadly.

John.

What version of LAME you use externally? Could you post your system info?

As I wrote earlier I didn't find big differences with LAME 3.93 and LAME 3.96.1 when using CBR 128.

LAME 3.96.1 is normally much faster when used with the highest quality VBR settings: --preset standard or --preset extreme. (With LAME 3.93 the same settings were written a bit differently: --alt-preset ...).

Edit

Matt, could you tell us if there are any functional differences with the LAME used internally in MC11 and a separate LAME 3.96.1 encoder (e.g. a compilation from rarewares.). See the size difference note I made earlier in this thread.

Make sure you're using LAME by choosing "MP3 Encoder".   Don't choose "External Encoder" because then on-the-fly ripping, and on-the-fly conversion won't work. (causing big slowdowns)

Matt,

I'm sorry I'm not being clear.

When I use the setting "MP3" in the file conversion settings I'm getting VERY slow speeds - this also applies to ripping/encoding. As I've posted previously in this thread it's up to 8/9 times slower than the equivalent settings in MC10.

When I use an external LAME encoder - set to "external encoder" - I get the sort of speeds I get in MC 10.

The issue is either the encoder that is used in MC 11 or the way it is configured in MC 11, for me at least.  

Matt,

I'll have another go - but please look at the comparison MC10/MC11 I posted ealier in this thread.

Also Alex B has noticed that the Lame.exe file in MC11 is substantially bigger than the one in MC10.

I'll swap the Lame.exe file in MC10 into the one in MC11, and also try it with the Lame.exe file I'm using through the external encoder route.

John.

Thanks for all the effort.

So in summary, it looks like the newer LAME is a lot slower with some settings or with some computers.

Maybe 3.96.1 isn't a good default.  Or maybe we should change the command line parameters.  Do any LAME gurus have more information?

Thanks for all the effort.

So in summary, it looks like the newer LAME is a lot slower with some settings or with some computers.

Maybe 3.96.1 isn't a good default.  Or maybe we should change the command line parameters.  Do any LAME gurus have more information?

3.96.1 should be faster. Even 3.95 about a year ago was faster than previous versions. Though I always encode with VBR, but I can run some more comprehensive CBR tests and try to find out something. For example at hydrogen audio forums everybody likes the speed of 3.96.1 and the only question is if it is any better quality wise than their old favorite 3.90.3. (not 3.93 included in MC10).

In my opinion all high bitrate audio quality differences between different LAME 3.9x versions are minor, but 3.96.1 should be the fastest and it should have better quality at low bit rates. Though, I am not sure about that anymore.

Matt, could you look at this link: http://www.hydrogenaudio.org/forums/index.php?showtopic=18091&st=0

MC could use the "-V 0" to "-V 9" switches for VBR ("-V 2" is the same as --alt-preset standard) and have an option for "fast" that uses "--vbr-new".

Perhaps there could be a slider with 10 different values and a tick box for "fast" and a field for custom command line.

I try to find out the current recommended CBR (and ABR) settings and possible speed issues.


Edit

This is also an interesting discussion: http://www.hydrogenaudio.org/forums/index.php?showtopic=28910.

Here is an example of the user interface by the LAME developers:
http://lame.sourceforge.net/lame_ui_example.html

I haven't piped in before because I haven't been willing to invest the time in troubleshooting this issue. However, I've found MC11 so slow at ripping that I've actually been using other programs for that purpose for the first time since . . . before I found MJ8? MC10 ripped/encoded at, say, 7x at least, and usually much higher. Since using MC11, my ripping/encoding speed rarely reaches 1x. A couple of weeks ago, before this thread was opened, I tried ininstalling/reinstalling MC, adjusting settings (such as the simultaneous rip and encode and analyze audio during ripping), but there was no speed inprovement. On the other hand, WMP, MusicMatch,EAC,Roxio, etc, all had normal ripping speeds. None of those programs had been installed for quite a while now, but now I keep one installed just for ripping/encoding purposes. Actually, like so many minor problems in MC, I really just assumed that you'd discover it on your own and fix it without much ado.

With all programs, I was encoding to mp3, cbr, 320 kbs/sec. So, it seems that the issue may be the particular LAME version, and not MC itself. Later, I'll try a different version of LAME in MC. I suppose that I wasn't all that concerned, as encoding with ape worked fine, and I'll be going ape again when I get a new HD (have to replace an elderly and ill drive).

Media Center Registered 11.0.118 -- C:\Program Files\J River\Media Center 11\

Microsoft Windows XP  Workstation 5.1 Service Pack 2 (Build 2600)
Intel Pentium 4 1771 MHz MMX / Memory: Total - 523 MB, Free - 230 MB

Internet Explorer: 6.0.2900.2180 / ComCtl32.dll: 5.82 (xpsp_sp2_rtm.040803-2158) / Shlwapi.dll: 6.00.2900.2180 (xpsp_sp2_rtm.040803-2158) / Shell32.dll: 6.00.2900.2180 (xpsp_sp2_rtm.040803-2158) / wnaspi32.dll: N/A
Ripping /   Drive E:   Mode:Normal  Type:Auto  Speed:Max
  Digital playback: Yes /  Use YADB: Yes /  Get cover art: Yes /  Calc replay gain: No /  Copy volume: 32767
  Eject after ripping: Yes /  Play sound after ripping: No  

Burning /  Drive E: SAMSUNG  CD-R/RW SW-252B    Addr: 1:0:0  Speed:80  MaxSpeed:356  BurnProof:Yes
  Test mode: No /  Eject after writing: Yes /  Direct decoding: No /  Write CD-Text: Yes
  Use playback settings: No /  Normalization: None

This discussion has already changed from ripping to LAME encoding speed

I don't think that it was ever about ripping.  The person that started the thread said:

Checking the task manager shows Lame.exe is really hogging the resources, any chance V11 is using an experimental version of lame?

That sounds like an encoding issue, regardless of the topic name.

mhorton, I see your point.

However, in my opinion we could concentrate on resolving this problem if we like to help JRiver in building MC11.

I like to help if I can (even MC11 is not an open source project). I am going to use it a lot when it is ready and it is also my advantage if it works well in all aspects.  


sirshampling,

Thanks. Post your findings too. I hope that those settings are faster with your setup.

IMHO the topics are inter-realted as the slow ripping speeds and slow encoding speeds are the same issue if you're ripping/encoding at the same time - as I was.

Thanks to Alex's sleuthing the problem is the way that the LAME encoder installed by default in MC11 is set up in your Tools/Options.

My settings were 128 quality, and "high quality" under advanced. If you're using different settings like 320kbps - are you using "high quality"? If so that might be a link that will help Alex in his deliberations.

John

Then that could be the trouble - I'd suggest you try quality "custom" and then one of Alex's ideas in the command line.

I'm going to try out his thoughts and report back in the next day or so - perhaps you could do the same.

John.

Thanks Matt,

here is a confirmation:

From wave (5 minutes 20 seconds) to MP3, MC 11 default encoder

CBR 128 kbps

Quality: 128, Advanced: High Quality  encoding time: 3 min 27 s
Quality: Custom, Advanced: --preset cbr 128  encoding time: 31 s

CBR 320 kbps

Quality: 320, Advanced: High Quality  encoding time: 2 min 12 s
Quality: Custom, Advanced: --preset cbr 320  encoding time: 24 s

Thanks for finding the problem guys, i must admit you lost me a bit in the middle there, but i'm back with script now.
Just out of interest i tried ripping\encoding with it set to Normal (CBR 192) last night and it was up to about 4.5\5x which is a nice improvement. Still about half what i was getting with V10 but i guess now the J River boys know what the problem is we won't have to wait too long.
cheers all
mark

While we are vaguely on ripping..... anyone else having problems with with ripping two cds at once? I think V11 is getting confused, it shows the list with all the track names fine, but then after confirming the names of the second cd it said it had a problem and reset the first cd to unknown artist\unknown. I will see if i can repeat this....

VBR = variable bit rate. Files can be any size, quality is fixed. Simple songs compress more, complicated music needs more bits. VBR saves space or gives better quality than CBR using the same amount of the space.

ABR = average bit rate, should be about 128 kbps.

CBR = constant bit rate, so the bitrate is exactly what was asked.

How big the files are?

What was the test music sample?

What did you use for checking the bitrate? (Windows Explorer doesn't show correct bitrates for variable bitrate files.)

MC shows correct average bitrate values after importing.

This is a separate tool for checking MP3 files: http://guerillasoft.co.uk/EncSpot/download.html

Maybe the monophonic source makes some difference. LAME uses the "Joint Stereo" system. It combines some information if there is no channel separation.

If -V 6 gives you too small bitrates try e.g. -V 5 or -V 4. The audio quality will be better. The number can be from 0 to 9. The maximum quality setting is 0.

(this is only for LAME 3.96.1, LAME 3.93 works differently)

EDIT

I made a mistake: "-V 6" should have been "-V 5" (for about 130 kbps target bitrate with average music material).

This is a nice LAME/Joint Stereo explanation from CDex help file:

Joint Stereo :
In this mode, the encoder will make use of a correlation between both channels. The signal will be matrixed into a sum ("mid") and difference ("side") signal. For quasi-mono signals, this will give a significant gain in encoding quality. This mode does not destroy phase information like IS stereo that may be used by other encoders. This setting can be used to encode DOLBY ProLogic surround signals.

Could it be the simplicity of the music that makes a difference? My (very lmited) understand of non-CBR encoding is that the bitrate goes up the more "action" there is in the music.

Yes, VBR does that. That is why it is more suitable for high quality encoding. It uses more bits when it is necessary. Easy parts are compressed more. Find a proper "-V n" value for your 128 kbps encodings and you can be sure that you have the best possible MP3 quality at that bitrate class.