#1594 closed defect (fixed)
TOOLS: Problems with extract & LAME 3.95
| Reported by: | eriktorbjorn | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | high | Component: | Tools |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
Since there have been some reports of problems with the 'extract' tool and recent versions of LAME, but I have seen no proper bug report, I tried re-encoding my monster.sou files with LAME 3.95.
With Fate of Atlantis, LAME didn't accept the sounds where the original samplerate was given as A7 (11235 Hz) or A8 (11363 Hz).
With Day of the Tentacle, it didn't accept the sounds where the original rate was given as C8 (17857 Hz), CD (19607 Hz), CF (20408 Hz), D0 (20833 Hz), or D5 (23255 Hz).
I don't think there were any problems with Sam & Max, Full Throttle or the Simon games (simon2mp3 shares some code with extract). I don't know about the demos or the non-English versions.
I noticed that both extract and ScummVM itself approximates some samplerates as 11025 Hz and 22050 Hz. Is there any technical reason for this, other than keeping LAME happy? I didn't notice any problems when I tried to encode the files with oggenc, without the approximations. I didn't try FLAC. (This kind of testing is pretty time-consuming on my 450 MHz PIII...)
Ticket imported from: #934026. Ticket imported from: bugs/1594.
Change History (17)
comment:1 by , 21 years ago
comment:2 by , 21 years ago
Hello,
I encountered the same problems with extract/LAME 3.96 and can confirm your observations. I also tested the german language versions of the games and found no problem.
english german
ATLANTIS error n/a FT ok ok SAMNMAX ok ok SIMON1WIN ok ok SIMON2WIN ok ok TENTACLE error ok
I had no problems using extract/FLAC 1.1.0 with any game and language version from the above mentioned.
comment:3 by , 21 years ago
| Summary: | EXTRACT: Problems with LAME 3.95 → TOOLS: Problems with extract & LAME 3.95 |
|---|
comment:4 by , 21 years ago
Just to clarify this: We do not "approximate" the sample rates. Rather, we use the correct values -- the VOC format is simply to ba-roken to properly allow encoding all possible sample rates. Rather you can only store the closes fiting values in the VOC files. So even though the sounds are encoded using the quasi-standard rates of 11025 resp. 22050 Hz, the VOC format can't encode this, so the closes matchin values are used instead. The original engines played them as 10025/22050 anyway.
Luckily, even if you do playback with the invalid sample rate values stored in VOC files, most people won't notice the difference.
comment:7 by , 20 years ago
I have run into the same problem.. Any idea what versions work?
I had both Fate of Atlantis and DOTT fail as you described.
FT and Sam & Max worked fine.
comment:8 by , 20 years ago
Is it possible to avoid these errors with an older version of lame? If so, what version must be used?
comment:9 by , 20 years ago
I don't remember which version I used when it worked, but it might have been 3.93. I first came in contact with ScummVM in late June or early July 2002. Lame 3.93 was released in November that year.
But I do wish someone who understands the bug a bit better than I do would fix it. As far as I can understand, that would mean either fiddling with the options to lame to find something it likes better - after all, the documentation claims that lame will resample its input to something sensible, if necessary, so why doesn't it? - and/or change getSampleRateFromVOCRate() to map the "weird" sample rates to 22050. Fingolfin, you indicated that the original engine did the latter anyway, or did I misunderstand?
(If we change that function, it ought to be remembered that we have the same function in ScummVM itself.)
comment:10 by , 20 years ago
Thank you, I tried with lame 3.93.1 and it was all ok, no errors appeared.
comment:11 by , 20 years ago
| Priority: | normal → high |
|---|
comment:12 by , 20 years ago
I think we should be careful and not just blindly remap those sample rates to multiples to 11025. Maybe these sounds really are supposed to be played at those "odd" rates. To find out, I guess one would have to listen to the sounds at different rates and compare. Ideally, identify where in the game the sound is played to get the best impression (and be able to compare with the playback of the original).
Alternatively, one could disassemble the relevant part of the engine to determine how it deals with the VOC sample rates.
comment:13 by , 20 years ago
I just checked with the LAME docs (http://lame.sourceforge.net/USAGE). specifically the part regarding resampling:
" -s n
where n = sampling rate in kHz.
Required for raw PCM input files. Otherwise it will be determined from the header information in the input file.
LAME will automatically resample the input file to one of the supported MP3 samplerates if necessary. "
So at least in theory, it should work fine....
comment:14 by , 20 years ago
I just updated my system to lame 3.96.1, and was able to reproduce the problem. Encoding worked fine if I disabled VBR mode. It also worked if I used VBR mode but explicitly specified a target resampling frequency. So it seems automatic resampling in lame is (for some reason) disabled in VBR mode. I verified this in the lame source, indeed, only of VBR is off does lame compute an output sample rate.
So one possible solution would be for us to always specify "--resample FREQ" and choose an appropriate target frequency, out of the valid MP3 freqs: 8 12 11.025 16 24 22.05 32 48 44.1 What lame does there is to multiple the input sample rate by 0.97 (3% error margin), then take the next bigger MP3 rate as output rate. Of course one could also make this a user option.
comment:15 by , 20 years ago
| Status: | new → closed |
|---|
comment:16 by , 20 years ago
I added the described workaround to CVS (i.e. we now specify --resample when calling lame); so we now should get identical results with lame 3.93 and 3.95/3.96.
comment:17 by , 20 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
The way I read the manual page, LAME should automagically resample the sound to a samplerate it can handle. Except apparently 3.95 doesn't do that in these cases.