Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: lame and files > 2GB (Read 3978 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

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

 

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.

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.

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

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.