Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#1594 closed defect (fixed)

TOOLS: Problems with extract & LAME 3.95

Reported by: eriktorbjorn Owned by: fingolfin
Priority: high Component: Tools
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 Changed 15 years ago by eriktorbjorn

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.

comment:2 Changed 15 years ago by (none)

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 Changed 15 years ago by fingolfin

Summary: EXTRACT: Problems with LAME 3.95TOOLS: Problems with extract & LAME 3.95

comment:4 Changed 15 years ago by fingolfin

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:5 Changed 15 years ago by fingolfin

What is the status of this item?

comment:6 Changed 15 years ago by eriktorbjorn

Unchanged, I assume. I haven't done anything about it, anyway.

comment:7 Changed 15 years ago by SF/bagobones

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 Changed 15 years ago by SF/arbegas

Is it possible to avoid these errors with an older version
of lame?
If so, what version must be used?

comment:9 Changed 15 years ago by eriktorbjorn

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 Changed 15 years ago by SF/arbegas

Thank you,
I tried with lame 3.93.1 and it was all ok, no errors appeared.

comment:11 Changed 15 years ago by fingolfin

Priority: normalhigh

comment:12 Changed 15 years ago by fingolfin

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 Changed 15 years ago by fingolfin

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 Changed 15 years ago by fingolfin

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 Changed 15 years ago by fingolfin

Status: newclosed

comment:16 Changed 15 years ago by fingolfin

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 Changed 15 years ago by fingolfin

Owner: set to fingolfin
Resolution: fixed
Note: See TracTickets for help on using tickets.