>>IMHO, it is not sufficient to replace fopen. You need to replace all
>>the fseek(), ftell(), ... and variable type to store the result of
ftell64()
>>and so on. Of course, you should use configure for all of them.

>>Output may be bigger than input (when with --decode), so it is important.
>>But, by default, the output of decoding is RIFF-wave which does not
support
>>over 2GB.... So we have to check the length of decoded data.

I think two 'limits' are involved here:

2Gb limit for file streaming on some systems.
4Gb limit for RIFF WAVE format (max unsigned long).

I have tested the 'fopen64 only' lame I customized and it succesfully
encoded a 3.8 Gb RIFF Wave File under sun OS 5.8.
I understand it is not a very clean or safe method, and that the changes in
ALL streaming APIs should be configured, but it worked by changing just a
few lines of code. I think the correct calls for all streaming APIs in lame
may turn out in quite a big patch. I have to take a better look at the
source code.


What do you guys think is the best path to take ?


Michelangelo Nottoli
Multimedia Division
Advanced Computer Systems S.p.A.
Via della Bufalotta, 378 - Scala M
00139 Rome - Italy
Tel:     +39 (06) 87090513
Fax:     +39 (06) 87201502
http://www.acsmultimedia.com












_______________________________________________
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder

Reply via email to