Skip to main content

Topic: lame and files > 2GB (Read 2553 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • qristus
  • [*][*][*]
  • Members (Donating)
lame and files > 2GB
Does anyone know if lame has a problem with files > 2GB in size? I'm encoding the soundtrack to Spartacus (more than 3 hours in 24bit 48khz  ) , and lame reports the size of the file as 3578343 frames long, which is a bit too much to say the least. It might be that it'll just finish the encode when it reaches the end of the file, I'll see in half an hour or so... But even if that happens it's still a bit annoying

The file is on an NTFS volume, so this shouldn't be a FAT32 problem. I'm using the 3.90 alpha 8 build (12.10.2001) from http://www.hot.ee/smpman/mp3/.

  • h
  • [*][*]
lame and files > 2GB
Reply #1
I'd be very surprised if anyone bothered to add win32 large file handling code into LAME - when it hits the 2GB mark, something ugly will most likely happen (doubt there'll be anything to catch the error either).

Any reason you need the 24 bit input resolution?  I'm sure you can't tell all that much of a difference =)

-h

Edit: Just checked frontend.c and (if this is actually the command line encoder's front end) it won't be happy once it hits 2 GB mark, thanks to using stdio.h for its file access.  Could be wrong though.

  • qristus
  • [*][*][*]
  • Members (Donating)
lame and files > 2GB
Reply #2
Quote
Originally posted by h
I'd be very surprised if anyone bothered to add win32 large file handling code into LAME - when it hits the 2GB mark, something ugly will most likely happen (doubt there'll be anything to catch the error either).

Any reason you need the 24 bit input resolution?  I'm sure you can't tell all that much of a difference =)

-h
I probably couldn't tell the difference if I tried, but at least this way I know there's no quality lost unneccessarily  I actually did go down to 16 bit last week when this happened, but I'm afraid that won't help much in this case - even in 16 bit it'll still end up at 2072 MB (it's a _long_ movie  )

The encode finished now though, and it did actually stop on reaching the end of the file, even though it still claimed it was only 14% done... I'm at work right now so I can't listen to it and see if it's okay, but I'll post my results when I get back.

EDIT:[/b]
The mp3 file seemed okay at first, then I realised that it was about 10 minutes too long, and in the middle somewhere it suddenly skipped to an entirely different part. It was in sync with the movie up to that point though. However I can't play the original 24-bit wave file (grrr) to see if it's a problem with the wave or the encoding... I'll have a look at it again this evening.

  • niktheblak
  • [*][*][*][*]
  • Members (Donating)
lame and files > 2GB
Reply #3
Divida et impera!

The simplest solution possible would arise straight from the movie encoding scene where 2/4 GB limit is just normal routine.

Split the WAV into two separate wav's, encode both and join them with some mp3 joiner.

Google will surely give tons of programs for this purpose. However, I don't know do every mp3 joiner support even slightly larger files or know how to handle VBR headers..

  • qristus
  • [*][*][*]
  • Members (Donating)
lame and files > 2GB
Reply #4
Quote
Originally posted by niktheblak
Split the WAV into two separate wav's, encode both and join them with some mp3 joiner.

Google will surely give tons of programs for this purpose. However, I don't know do every mp3 joiner support even slightly larger files or know how to handle VBR headers..


I don't think the VBR headers would be much of a problem, I'm more worried about joining the two mp3 files at exactly the right sample - don't want to screw up synchronisation... But I'll see what I can do. I'll have a go at it again this weekend.