Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[milknkukis]

Hi gang
I know this was discussed a while back but now i can't find it.
What was the solution to slow rip speeds in V11? I remember reading the thread but thought "that doesn't apply to me so i will forget it" ... just to find it does now i have started ripping a few new cd's.
I have been using V11 for just over a month, (over 20 versions!! nice one guys!) but i remember getting ripping speeds in V10 around 9x ~ 11x, now i'm getting ) 0.9x ~ 1.2x.
As far as i know nothing has changed, what do i need to check?

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

Microsoft Windows XP  Workstation 5.1 Service Pack 2 (Build 2600)
Intel Pentium 4 2398 MHz MMX / Memory: Total - 523 MB, Free - 136 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 D: HL-DT-STDVD-ROM GDR8161B  Mode:Normal  Type:Auto  Speed:Max
  Drive E: TEAC    CD-W548E          Mode:Normal  Type:Auto  Speed:Max
  Drive H:   Mode:Normal  Type:Auto  Speed:Max
  Drive I:   Mode:Normal  Type:Auto  Speed:Max
  Drive J:   Mode:Normal  Type:Auto  Speed:Max
  Digital playback: Yes /  Use YADB: Yes /  Get cover art: Yes /  Calc replay gain: Yes /  Copy volume: 32767
  Eject after ripping: Yes /  Play sound after ripping: No  

Burning /  Drive E: TEAC     CD-W548E           Addr: 1:1:0  Speed:48  MaxSpeed:48  BurnProof:Yes
  Test mode: No /  Eject after writing: Yes /  Direct decoding: Yes /  Write CD-Text: Yes
  Use playback settings: No /  Normalization: None

[LonWar]

What are drives H, I and J?

Are they virtual?

[milknkukis]

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

[LonWar]

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

The reason I asked is, I used to have a virtual drive (Pinnacle) and it wreaked havoc on MC, Slow rips slow everything.

You may want to disable them and see if that makes a diff.

[JimH]

Good find, gamer!

[LonWar]

Good find, gamer!

I guess the question left is, Jim can you guy's fix this? This is only an issue with MC...

[milknkukis]

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

[JimH]

Doubtful.  That it happens only with MC still doesn't tell you where the problem is.

[milknkukis]

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?

[sirshambling]

I've had exactly the same ripping speed problem with MC11 as against MC10 ever since I moved to the new version. Also very slow file conversion speed from WAV to MP3.

No virtual drives, same settings (unless there's a setting elsewhere other than Tools/Options/Devices or Encoding).

I wondered in a previous post in another thread if this was an MP3 coding issue and didn't get a response. Is there a way of testing this by installing a different encoder?

John

[Alex B]

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.

[milknkukis]

Thanks Alex, that gives me a few things to play with. Unfortunately i'm heading off for a long weekend this evening so it will have to wait, but i'll get back to you as soon as i can.
The "Rip and encode simultaneously" option might be worth playing with, i have always had it ticked. Are you saying that you do the processes seperately? You rip to wave THEN convert the files? Does that not take up alot of time?
cheers again
mark

[sirshambling]

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.

[KingSparta]

MC11 "MP3 Encoder" uses the newer "lame" encoder

[Alex B]

... 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]

Thanks again for your comments Alex.

There must be some key difference between MC10 and MC11 on my PC - but I've no idea what it might be!

As for 128 kbps - the music I listen to was recorded on 4 track at best, no point in going to anything more subtle!

Hope you have a good evening with your guests.

John.

[Alex B]

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.

[sirshambling]

Hello Alex,

Thanks for taking the time/trouble to get involved again!

The default MP3 encoder I'm using with MC11 is set at CBR 128, and "high quality" under "advanced". These settings are identical to those I use for MC10.

The external LAME encoder I got from the site you kindly pointed out and I'm using the 3.96.1 stable version and the settings in the MC 11 "box" are %IN %OUT -h -b 128.

My system specs are:-

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 3069 MHz MMX / Memory: Total - 1048 MB, Free - 387 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: 4.71 (0002) , ASPI for Win32         DLL, Copyright © 1989-2002 Adaptec, Inc. / Aspi32.sys: 4.71 (0002)

Ripping /   Drive S: JLMS    XJ-HD165H         Mode:ModeSecure  Type:Auto  Speed:Max
  Drive T:   Mode:ModeSecure  Type:Auto  Speed:Max
  Digital playback: Yes /  Use YADB: Yes /  Get cover art: No /  Calc replay gain: Yes /  Copy volume: 32767
  Eject after ripping: Yes /  Play sound after ripping: No  

Burning /  Drive T: LITE-ON  LTR-48125S         Addr: 3:0:0  Speed:28  MaxSpeed:48  BurnProof:Yes
  Test mode: No /  Eject after writing: Yes /  Direct decoding: No /  Write CD-Text: Yes
  Use playback settings: Yes /  Normalization: None

[Matt]

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)

[bjevers]

Encoding is taking a long time on my MC11 setup too.  I unchecked the Rip and Encode simultaneously and I got a rip speed of 16x for track 1.  With the option checked, I get 1.1x.  I am using the built in LAME encoder set to Quality: High and under Advanced I set Quality to High Quality.  BTW, what is the difference in these settings?  With MC10 I used Rip and Encode together and had fast speeds.

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)
AMD Athlon 2576 MHz MMX / Memory: Total - 1048 MB, Free - 555 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: 4.71 (0001) , ASPI for Win32 (95/NT) DLL, Copyright © 1989-2002 Adaptec, Inc. / Aspi32.sys: 4.71 (0001)

Ripping /   Drive G: LITE-ON LTR-48125W        Mode:Normal  Type:Auto  Speed:Max
  Drive H:   Mode:Normal  Type:Auto  Speed:Max
  Drive I:   Mode:Normal  Type:Auto  Speed:Max
  Digital playback: Yes /  Use YADB: Yes /  Get cover art: Yes /  Calc replay gain: Yes /  Copy volume: 32767
  Eject after ripping: No /  Play sound after ripping: No  

Burning /  Drive G: LITE-ON  LTR-48125W         Addr: 2:2:0  Speed:48  MaxSpeed:48  BurnProof:Yes
  Drive H: SONY     DVD RW DRU-500A    Addr: 2:3:0  Speed:5  MaxSpeed:5  BurnProof:Yes
  Test mode: No /  Eject after writing: No /  Direct decoding: Yes /  Write CD-Text: Yes
  Use playback settings: No /  Normalization: None

[sirshambling]

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]

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.  

MC uses the LAME.exe in your MC\Plugins directory.  You can test different versions by swapping that file.  Pick 'Advanced' and enter command line parameters so you can do an exact comparison with MC 10.

Any more details you could mine by playing around with MC 10 vs. MC 11 with the steps above would be great.

Thanks.

[sirshambling]

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.

[sirshambling]

OK here's what I've tried.

Opened MC11 and via Tools/Options set the File Conversion to MP3 encoder, 128 quality, and under "advanced" put the setting at "high quality". (Matt - no option to use a command line setting - should there be one?).

Converted duplicate copies of the same WAV file at 3.03 long using the same settings but swapping over the LAME.EXE file in the plugins directory of MC11.

The results are:-

MC10 LAME – 26 secs
MC11 LAME – 89 secs
LAME 3.96.1 from Rarewares.com – 89 secs
LAME 3.93.1 from Rarewares.com – 27 secs

Allowing for the vagaries of my timing there's clearly something about the way Lame 3.96.1 (which I believe you use as default in MC11) operates within MC11.

So I tried using the same test in MC10 using the same files and the same encoding settings.

The results are:-

MC10 LAME – 27 secs
MC11 LAME – 89 secs
LAME 3.96.1 from Rarewares.com – 89 secs
LAME 3.93.1 from Rarewares.com – 27 secs

So I think the same issue applies to MC10.

Hope this is of some use.

John

[Matt]

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?

[sirshambling]

No problem - obviously some are affected some aren't.

I hope you sort it out - for the moment as my work-around I'll leave 3.93.1 as the LAME encoder.

John

[Alex B]

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.

[JimH]

Thanks, Alex.

Sirshambing,
Maybe you could try VBR?

Also, if you haven't tried, turn off MC's simultaneous rip and encode.

Listening to: 'Respect' from 'Elizabeth's Car' by 'Aretha Franklin' on Media Center 11

[Alex B]

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

[Alex B]

I found this: http://cdexos.sourceforge.net/boards/index.php?s=27e95d85ba06138340b427a68c04fd9a&showtopic=2340

sirshambling,

You should not use "Advanced > High quality".

LAME 3.96.1 needs new internal parameters as Matt thought. I try soon to help with that. Maybe I run some tests over the next few days and post here a table about my suggestions.

You could use these 128 kbps switches for now:

quality: custom,  advanced:

-V 5  VBR, usually averages at 130 kbps, best audio quality, can be higher than 128 kbps if needed for complex music tracks.
     or
--preset 128  ABR, variable but forced to 128 kbps, better than CBR
     or
--preset cbr 128  CBR, lowest quality of these three, but still very good.

EDIT

Corrected a mistake. -V 6 changed to -V 5

[Michael Horton]

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

[Alex B]

This discussion has already changed from ripping to LAME encoding speed. Secure ripping is always slower with MC and also with EAC.

For LAME 3.96.1 the best 320 kbps CBR command line is simply:
--preset CBR 320. Try the speed with it.

I will run tests later, but I am almost sure that the "Advanced > High quality" option is dated and should be replaced with a new switch.

[Michael Horton]

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.

[sirshambling]

Alex,

Thanks very much indeed for the info - really helpful.

I'll give your suggestions a go over the next few days. If you get any more thoughts I'd love to read them.

John.

[Alex B]

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.

[Michael Horton]

in my opinion we could concentrate on resolving this problem

Good idea. I'm prone to wandering off topic, sorry. But, which problem is it we're tring to solve again? Is it the encoding problem that the thread originator was having, or the secure ripping problem that was brought up part way into the thread?

Anyway, tried ripping with MC11.0.118 again, and found that I misspoke earlier. Ripping is occurring at a normal speed on my machine  but encoding with the internal mp3 encoder at 320 kbs is terribly, terribly slow. It takes about 90 minutes to encode a 45 minute CD. Sorry if this is offtopic.

[sirshambling]

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

[Michael Horton]

If you're using different settings like 320kbps - are you using "high quality"?

That's the setting that I use, yes.

[sirshambling]

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.

[Matt]

This issue is that selecting "High" from quality uses the (now) incredibly slow -q0 flag.

We'll roll to the new --preset system in a coming build of MC 11.  Until then, use "Normal" quality.

Thanks for all the help everyone.

[Alex B]

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

[Alex B]

Any hope that MC will have something like that example UI?

http://lame.sourceforge.net/lame_ui_example.html

It looks very logical and it almost forces the user to make the optimal selections.

In my opinion iTunes, MMJB and WMP have mediocre user interfaces for MP3 options. MC could be the best in the industry also in this area.

[milknkukis]

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....

[sirshambling]

Alex,

Just done a highly unscientific test on the 3 MP3 settings you suggested.

Results on a file conversion of 2.35 WAV track are:-

"-V 6  VBR, usually averages at 130 kbps, best audio quality, can be higher than 128 kbps if needed for complex music tracks."

Bitrate shows as "84" not 128 or 130 - time 23 secs.
   
"--preset 128  ABR, variable but forced to 128 kbps, better than CBR"

Bitrate shows as "108" not 128 - time 19 secs.
   
"--preset cbr 128  CBR, lowest quality of these three, but still very good"

Bitrate shows as "128" (hoorah!) - time 22 secs.

Something very odd is going on!

John

[Alex B]

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

[sirshambling]

The files were duplicates of a 2.35 WAV track that I digitized onto the PC from a 45 rpm mono vinyl record imported using Sound Forge 7 to a stereo WAV file, 44.1, 16bit - which is where the vast majority of my music tracks come from. I'ts certainly not "state of the art" digital but I clean the tracks up before importing them into MC11 (apart from this build!) and encoding them to MP3.

I got the bitrates from MC11 after the encoding. The number chaged from 1411 to the numbers I gave.

I'll have a go at other settings a little later tonight I hope.

John.

[Alex B]

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).

[sirshambling]

Thanks Alex.

I wouldn't have thought the mono source would make a difference - as by the time the encoder looks at the file it' a stereo WAV file in the standard format.

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.

I'm using 3.96.1 and need to experiment a bit more I think with differenr settings as you suggest.

Thanks once again.

John

[Alex B]

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.

[Matt]

Updated and improved MP3 Encoder available here:
http://yabb.jriver.com/interact/index.php?board=3;action=display;threadid=24526