R: [mp3encoder] lame and files larger than 2Gb
>>I suggest to use the defines FOPEN and _LARGEFILE_SOURCE I checked : _LARGEFILE_SOURCE is defined under Sun all right. I am very ignorant on other 64 bit systems though. thanks 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
R: [mp3encoder] lame and files larger than 2Gb
>>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
Re: [mp3encoder] lame and files larger than 2Gb
Hi, Michelangelo! Over 2GB support was requested for a long time. http://sourceforge.net/tracker/index.php?func=detail&aid=849889&group_id=290&atid=100290 But it is quite hard to support it "flawlessly" (at least for me...) From: Alexander Leidinger <[EMAIL PROTECTED]> Subject: Re: [mp3encoder] lame and files larger than 2Gb Date: Thu, 29 Jan 2004 16:10:31 +0100 > On Thu, 29 Jan 2004 13:43:27 +0100 > "Michelangelo Nottoli" <[EMAIL PROTECTED]> wrote: > > > (question 1) > > > > can anyone suggest the correct #ifdefs for fopen/fopen64 calls? something > > like... > > > > #if defined(__unix__) || defined(__sun__) > > ...call fopen64 > > #else > > ..call fopen > > #endif > > > > sounds correct ? > > The should be a configure test for fopen64. If the function is available > it can get used. 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. > > (question 3) > > > > do you think there is need to open the output stream also with fopen64 ? > > I think it would be better. 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. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] lame and files larger than 2Gb
On Thu, 29 Jan 2004 13:43:27 +0100 "Michelangelo Nottoli" <[EMAIL PROTECTED]> wrote: > (question 1) > > can anyone suggest the correct #ifdefs for fopen/fopen64 calls? something > like... > > #if defined(__unix__) || defined(__sun__) > ...call fopen64 > #else > ..call fopen > #endif > > sounds correct ? The should be a configure test for fopen64. If the function is available it can get used. Checking for __unix__ is completely wrong, as there's no guarantee it is available. FreeBSD doesn't has fopen64, the fopen function already provides the necessary functionality. I suggest to use the defines FOPEN and _LARGEFILE_SOURCE (I was told this define needs to be present if you compile with such 64 bit functions): ---snip--- #if defined(_LARGEFILE_SOURCE) # define FOPEN fopen64 #else # define FOPEN fopen #endif ---snip--- Now modify every call to be FOPEN(...) instead if fopen(...). > (question 2) > is there any chance to see this modification on the lame distribution/tar ? Yes, check out the current CVS version and provide a diff (cvs diff) of your modifications. Add the diff to the patch submission section (http://sourceforge.net/tracker/?group_id=290&atid=300290) and send a note to the lame development list (see the CC of this mail). > (question 3) > > do you think there is need to open the output stream also with fopen64 ? I think it would be better. Bye, Alexander. -- I will be available to get hired in April 2004. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
[mp3encoder] lame and files larger than 2Gb
hello all from a newbie, I have a few questions about lame source code since lame uses 'fopen' to open files, on some systems (solaris is my problem) it cannot open files larger than 2Gb. I have modified the source in order to call fopen64 (file getaudio.c line~1261) for opening of the input file. I tested it and it seems to work (question 1) can anyone suggest the correct #ifdefs for fopen/fopen64 calls? something like... #if defined(__unix__) || defined(__sun__) ...call fopen64 #else ..call fopen #endif sounds correct ? (question 2) is there any chance to see this modification on the lame distribution/tar ? (question 3) do you think there is need to open the output stream also with fopen64 ? Example : If someone would try to decode a 3 hours mp3 file into a linear 48kHz file with lame, what would happen to the output stream when it reaches the 2Gb limit ? thanks very much, 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 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 ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
