INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: VBR File Size Estimates WAY off  (Read 1695 times)

eCo

  • Recent member
  • *
  • Posts: 22
VBR File Size Estimates WAY off
« on: August 13, 2006, 04:12:48 pm »

Hi all,

I've done a pretty exhaustive search, but haven't seen anything that addresses this issue directly.

I have a 1 Gig iRiver iFP-799 player, and am running MC v. 11.1.183.  I have a large FLAC library and am forcing a conversion to the device for both size and compatibility.  I'm a bit of a music quality nut and want to squeeze as much sound at the lower bit rates as I can, so VBR is my preferred format.

I went to a lot of trouble setting up nested smartlists that serve up a nice mix of albums/tracks.  Since I'm new to MC, this took more than a little education.  Fortunately, a lot of great help was to be had on the other board here. ;D

I then set out to have it generate about 1 Gig worth of material post-transcribing the formats.  I limited the smartlist to overall playing duration (e.g. 900 minutes) as that seemed to me to provide the best estimate of overall file size (at a specific bitrate).  This number was arrived at emprically by watching the iRiver device storage availability in the device view.

When I sync'ed the device, I was amazed to discover that instead of having the 30 MB or so of the predicted excess capacity, I had in fact about 400 MB!  This happened regardless of whether I picked the MP3 or WMA codecs.  It also didn't seem to vary much with music selection (perhaps because the smartlist generates a varied mix of rock, folk, and jazz).  Because MC will not allow me to sync if the smarlist estimate is even 1 MB above the capacity of the device, I effectively can't use that beautiful smartlist I worked so hard on.

Interestingly, if I use CBR - the smartlist estimate is quite accurate.  This suggests the poor estimate is not on the decoding side of things, but on the encoding side.

So, does anyone know if this is a universal problem?  If so, will it be addressed in a later version?

As I implied above, a simple work-around would be to allow MC to 'overfill' a device.  I could then derive a much closer fit.  If a device did become full, MC wouldn't crash - or would it?  ?  Now that I think about it, I have also experienced the 'FLAC crash' issue when cancelling a transfer that I've read about elsewhere on this forum.  So perhaps it would crash in my case.

Thanks for any and all help.

eCo

P.S. I should also mention, that except for this issue - I love this proggy.  I've tried all the others out there, and they're crap.

System:
WinXP SP2
Athlon X2 4000
nForce4 SLI
Logged

eCo

  • Recent member
  • *
  • Posts: 22
Re: VBR File Size Estimates WAY off
« Reply #1 on: August 17, 2006, 12:03:50 am »

^bump^

No one else has seen this problem?  Or should I have posted in the MC software forum?

eCo
Logged

BartMan01

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 1513
Re: VBR File Size Estimates WAY off
« Reply #2 on: August 17, 2006, 05:56:24 pm »

Don't have the same issue with my iPod using APE files.  It may be a FLAC issue, since FLAC isn't natively supported by MC - MC may have a problem with estimating compression on those files (just a wild guess).

I tested this using APE to a 256 MB flash drive.  It was pretty much spot on for me.  I kept deleting files from the queue till it let me sync, and the device only has 10mb of free space left.  It could have put one or two more files on, but nothing like the discrepancy you are seeing.

I am using the standard LAME encoder with 'high' and fast mode set.
Logged
Pages: [1]   Go Up