Hanayaka Nari Wa ga Ichizoku strange MP3 mono voice

Question

Hanayaka Nari Wa ga Ichizoku strange MP3 mono voice

daniel229 opened this issue 11 years ago · 38 comments

Accordance to http://www.emunewz.net/forum/showthread.php?tid=149045
the voice is a mono MP3.

06:59:370 user_main 06:59:418 06:59:418 06:59:419 NowLoading 06:59:488 user_main 06:59:622 user_main 06:59:654 user_main 06:59:687 user_main 07:09:431 user_main 07:21:643 user_main 07:23:646 user_main 07:25:564 user_main 07:27:516 user_main 07:34:206 user_main 07:34:573 user_main 07:34:589 user_main 07:34:611 ThreadCtrl 07:34:623 user_main 07:41:180 user_main 07:43:816 user_main 07:44:383 user_main 07:44:400 user_main 07:44:401 ThreadCtrl 07:44:433 user_main I[KERNEL]: HLE\sceKernelThread.cpp:2180 sceKernelStartThread(thread=298, argSize=0, argPtr=00000000)
Sound Thread I[ME]: HLE\sceAtrac.cpp:1272 0=sceAtracSetDataAndGetID(08a6c3c0, 00126424)
Sound Thread W[ME]: HLE\sceAtrac.cpp:1162 This is an atrac3+ stereo audio
I[KERNEL]: HLE\sceKernelThread.cpp:2299 sceKernelExitDeleteThread(0)
I[IO]: HLE\sceIo.cpp:837 stdout: 071.gim Loaded
I[IO]: HLE\sceIo.cpp:837 stdout: 700.gim Loaded
I[IO]: HLE\sceIo.cpp:837 stdout: 071.gim CountPlus
I[IO]: HLE\sceIo.cpp:837 stdout: 071.gim CountPlus
E[ME]: HLE\sceMp3.cpp:589 sceMp3ReleaseMp3Handle: bad mp3 handle 00000000
E[ME]: HLE\sceMp3.cpp:589 sceMp3ReleaseMp3Handle: bad mp3 handle 00000000
E[ME]: HLE\sceMp3.cpp:589 sceMp3ReleaseMp3Handle: bad mp3 handle 00000000
E[ME]: HLE\sceMp3.cpp:589 sceMp3ReleaseMp3Handle: bad mp3 handle 00000000
E[ME]: HLE\sceMp3.cpp:589 sceMp3ReleaseMp3Handle: bad mp3 handle 00000000
E[ME]: HLE\sceMp3.cpp:589 sceMp3ReleaseMp3Handle: bad mp3 handle 00000000
I[ME]: HLE\sceMp3.cpp:533 sceMp3GetInfoToAddStreamData(09FFF5B8, 08A615C4, 09FFF5DC, 09FFF5D8)
I[KERNEL]: HLE\sceKernelThread.cpp:2180 sceKernelStartThread(thread=280, argSize=4, argPtr=08a621ac)
I[KERNEL]: HLE\sceKernelThread.cpp:2273 sceKernelExitThread(0)
I[ME]: HLE\sceMp3.cpp:561 sceMp3NotifyAddStreamData(09FFF5B8, 29232)
E[ME]: HLE\sceMp3.cpp:589 sceMp3ReleaseMp3Handle: bad mp3 handle 09fff5b8
E[ME]: HLE\sceMp3.cpp:589 sceMp3ReleaseMp3Handle: bad mp3 handle 09fff5b8
I[ME]: HLE\sceMp3.cpp:533 sceMp3GetInfoToAddStreamData(09FFF5B8, 08A615C4, 09FFF5DC, 09FFF5D8)
I[KERNEL]: HLE\sceKernelThread.cpp:2180 sceKernelStartThread(thread=280, argSize=4, argPtr=08a621ac)
I[KERNEL]: HLE\sceKernelThread.cpp:2273 sceKernelExitThread(0)
I[ME]: HLE\sceMp3.cpp:561 sceMp3NotifyAddStreamData(09FFF5B8, 37008)

Answer 1 · 2014-04-05T14:00:32.000Z

I'm trying to log the channels/samplerate/bitrate @ #5804 to see if the ffmpeg return the header the correct here.

Answer 2 · 2014-04-05T17:19:13.000Z

JPCSPtrace log with scemp3
https://gist.github.com/sum2012/e2d513c55342c40f5e12
PPSSPP scemp3 debug log with fix sceMp3ReleaseMp3Handle return value 0
https://gist.github.com/sum2012/e2826b981a58baf00eb8

Real PSP return error code in sceMp3Decode
Sound Thread VOI - sceMp3Decode 0x0, 0x9F8D7A8 = 0x807F00FD

edit:I take a search
Most likely an error code meaning that the header is not a valid mp3header. That's the case when you have an ID3 tag at the start of the mp3. sceMp3 doesn't parse that unfortunately, so you have to do it yourself (and give the proper streamStart/streamEnd address to mp3InitArgs) or strip id3 tags from the mp3s you play

Answer 3 · 2014-04-06T03:43:29.000Z

Other than ocassionaly returning of 0x807F00FD in sceMp3decode , jpcsptrace always return 0x1200 but we are returning 0x900 only

Answer 4 · 2014-04-06T03:46:13.000Z

Well, 0x1200 is double 0x0900. Maybe something to do with mono/stereo?

-[Unknown]

Answer 5 · 2014-04-06T03:52:15.000Z

Mostly likely .

https://code.google.com/p/jpcsp/source/browse/trunk/src/jpcsp/HLE/modules150/sceMp3.java?spec=svn3463&r=3463#237

Answer 6 · 2014-04-06T04:10:27.000Z

Force return 0x1200 still have strange MP3 voice

Answer 7 · 2014-04-06T04:15:49.000Z

Yep I tried as well probably need to change others elsewhere

Answer 8 · 2014-04-06T04:28:57.000Z

Well, I would guess it's not writing enough samples or whatever. Just looking at the return value is very "skin deep".

-[Unknown]

Answer 9 · 2014-04-06T06:27:10.000Z

should be fixed here kaienfr@e9c605a

Answer 10 · 2014-04-06T06:41:49.000Z

Thanks @kaienfr . The voice sounds good now in this game .

FYI .Downstream panic is now getting lots of error decoding.

41:15:924 thread mp3 p E[ME]: HLE\sceMp3.cpp:198 avcodec_decode_audio4: Error decoding audio, return -1094995529
41:15:924 thread mp3 p I[ME]: HLE\sceMp3.cpp:252 sceMp3CheckStreamDataNeeded(0bebca38)
41:15:924 thread mp3 p I[ME]: HW\MediaEngine.cpp:79 FF: Header missing
41:15:924 thread mp3 p E[ME]: HLE\sceMp3.cpp:198 avcodec_decode_audio4: Error decoding audio, return -1094995529
41:15:924 thread mp3 p I[ME]: HLE\sceMp3.cpp:252 sceMp3CheckStreamDataNeeded(0bebca38)
41:15:924 thread mp3 p I[ME]: HW\MediaEngine.cpp:79 FF: Header missing
41:15:924 thread mp3 p E[ME]: HLE\sceMp3.cpp:198 avcodec_decode_audio4: Error decoding audio, return -1094995529

Answer 11 · 2014-04-06T06:51:43.000Z

The decoding error is normal, I know.
That's due to the fact that the mp3 file is read part by part into buffer.
So when mp3 decoder try to decode the last incomplete frame at the end of the buffer, surely, you will get such errors. But it's nothing since I have modfied the way to fill the buffer, and if we detect such incomplete frame, we will reread it again in the next load. But we can still obvserve some error after reloading especially the first two frames. I am not sure why, it seems that ffmpeg try to read again and again the last error frame at the end of the buffer and giveup after few tries to restart from the begining of its buffer.

PS: some of sceMp3 functions are really not working well, we need deep improvement. I try to rewrite most of functions and make them in a more resonable way, but I know it's still not perfact.

Answer 12 · 2014-04-06T09:14:10.000Z

Great, sounds much better now.

Answer 13 · 2014-04-06T09:34:54.000Z

I see. thanks @kaienfr

Answer 14 · 2014-04-06T10:36:46.000Z

With pleasure!
Anyway, I think sceMp3 still need to be improve further more since some games like miku still can not normally playing custom mp3. In my above branch, I have fixed the issue that we can already explore the mp3 files in the game, but only the first few frames are played, then stopped. That's still a mistery issue...

Answer 15 · 2014-04-14T20:57:00.000Z

Probably this one can ve closed now?

Answer 16 · 2014-04-14T20:58:55.000Z

Can someone confirm this plays correctly now?

Answer 17 · 2014-04-14T21:07:33.000Z

@hrydgard , I can confirm: it is working fine now.

Answer 18 · 2014-04-15T01:32:02.000Z

No,the voice is too fast.

Answer 19 · 2014-04-15T01:39:57.000Z

emm, the voice seems little bit fast but slower than before. still have no idea on this issue.

Answer 20 · 2014-04-15T02:14:49.000Z

Probably not prefect yet but previously when I tried to move frame to heap , it did sound better.Anyway I eill test it again.

Answer 21 · 2014-04-15T09:53:34.000Z

frame_ is actuelly in heap. It's only allocated in class constructor, and deallocate in destructor.
In fact, currently, we have only packet is in stack.

Answer 22 · 2014-04-15T13:47:56.000Z

@kaienfr .I see. then i think should be the same sound quality . I did remmeber of your old mp3 build fixes did sound bit better than the current master .I will check this out when i've time tonight.

Answer 23 · 2014-04-15T14:13:17.000Z

@raven02 yeah, it seems that in one of my previois commit, there is one better speed than the current state, but I have forgotten how it works,already few weeks ago...

Answer 24 · 2014-07-31T08:47:21.000Z

How is this one sounding now?

Answer 25 · 2014-07-31T09:12:01.000Z

Missing the last several words.

Answer 26 · 2021-01-18T23:24:02.000Z

Per #13333 this is too slow in v1.9.3 and higher. That means #12005, and might mean an issue with the delay in sceMp3Decode possibly.

Neither speed (before or after those changes) was right, and maybe now there's just something else still wrong.

-[Unknown]

Answer 27 · 2021-01-19T14:42:58.000Z

The bad sound maybe from
40:06:777 idle0 E[SCEAUDIO]: hle__sceaudio.cpp:355 Channel 8 buffer underrun at 36 of 46
full log v1.10.3-1564-g720c5b417:
ppsspplogv1.10.3-1564-g720c5b417.txt.zip

I will test again in real psp in next day at 9:00 pm in home.

Answer 28 · 2021-01-20T13:31:45.000Z

The sound is right in real psp

Answer 29 · 2021-01-23T20:24:16.000Z

Re-doing JPCSPTrace of @unknownbrackets version
https://gist.github.com/sum2012/8f4f7c8972b3be353d75b30aa08df4ef
I find 2 point:

1: In the real psp ,It call sceMp3ReleaseMp3Handle first but we call sceMp3Init first.
2: Find another error code 0x80671103 in sceMp3Decode

03:58:23.997121 Sound Thread VOI - -> sceMp3Decode 0x0, 0x9F8B4A4 = 0x0
03:58:23.998772 Sound Thread VOI - <- sceMp3Decode 0x0, 0x9F8B4A4 = 0x1200
03:58:24.033163 Sound Thread VOI - -> sceMp3Decode 0x0, 0x9F8B4A8 = 0x0
03:58:24.036294 Sound Thread VOI - <- sceMp3Decode 0x0, 0x9F8B4A8 = 0x1200
03:58:24.151928 user_main - -> sceMp3ReleaseMp3Handle 0x0 = 0x0
03:58:24.151993 user_main - <- sceMp3ReleaseMp3Handle 0x0 = 0x0
03:58:24.069602 Sound Thread VOI - -> sceMp3Decode 0x0, 0x9F8B4A4 = 0x0
03:58:24.830098 Sound Thread VOI - <- sceMp3Decode 0x0, 0x9F8B4A4 = 0x80671103
03:58:24.886017 user_main - -> sceMp3ReleaseMp3Handle 0x0 = 0x0
03:58:24.886083 user_main - <- sceMp3ReleaseMp3Handle 0x0 = 0x0
03:58:26.354167 user_main - -> sceMp3ReleaseMp3Handle 0x0 = 0x0
03:58:26.354236 user_main - <- sceMp3ReleaseMp3Handle 0x0 = 0x0
03:58:26.921503 user_main - -> sceMp3ReserveMp3Handle 0x9FFAFB8 = 0x0
03:58:26.921576 user_main - <- sceMp3ReserveMp3Handle 0x9FFAFB8 = 0x0
03:58:26.921616 user_main - -> sceMp3GetInfoToAddStreamData 0x0, 0x8A615C4, 0x9FFAFDC, 0x9FFAFD8 = 0x0
03:58:26.921655 user_main - <- sceMp3GetInfoToAddStreamData 0x0, 0x8A615C4, 0x9FFAFDC, 0x9FFAFD8 = 0x0
03:58:26.971416 user_main - -> sceMp3NotifyAddStreamData 0x0, 0x9090 = 0x0
03:58:26.971483 user_main - <- sceMp3NotifyAddStreamData 0x0, 0x9090 = 0x0
03:58:26.971520 user_main - -> sceMp3Init 0x0 = 0x0
03:58:26.972977 user_main - <- sceMp3Init 0x0 = 0x0

Answer 30 · 2021-01-24T08:22:30.000Z

Moving to milestone 1.12 for more investigation into the resampling functionality. Workaround is merged.

Answer 31 · 2021-01-24T09:21:48.000Z

Update log to v1.10.3-1625-g5686b3a64-windows-amd64
https://gist.github.com/sum2012/dfcb9a0b6dcf2c7e7ac9fe5df4ab40fa

Answer 32 · 2021-01-24T10:07:33.000Z

I will to try to test other games have problem or not
https://report.ppsspp.org/logs/kind/1036

Answer 33 · 2021-01-24T15:47:10.000Z

So just to make sure, the audio sounds right now?

That means treating the 32kHz audio as if it was 44.1kHz audio and resampling to 32kHz (therefore actually resampling to ~23kHz) is the solution? Or, more likely the logic in the method is somehow messed up and that's not actually what it does?

If it's not messed up, that might imply we're treating mono/stereo wrong because ~23kHz is near 22.05kHz.

-[Unknown]

Answer 34 · 2021-01-24T22:45:35.000Z

Yes, the audio sounds right now

Answer 35 · 2021-01-25T07:13:26.000Z

Okay, I need a bit more information - my tests are still not allowing that, but maybe it's an issue with my test. In sceMp3.cpp:

Find:

		DEBUG_LOG(ME, "startPos %llx endPos %llx mp3buf %08x mp3bufSize %08x PCMbuf %08x PCMbufSize %08x",
			Au->startPos, Au->endPos, Au->AuBuf, Au->AuBufSize, Au->PCMBuf, Au->PCMBufSize);
	} else {

Replace:

		ERROR_LOG(ME, "SceMp3InitArg startPos %llx endPos %llx mp3buf %08x mp3bufSize %08x PCMbuf %08x PCMbufSize %08x",
			Au->startPos, Au->endPos, Au->AuBuf, Au->AuBufSize, Au->PCMBuf, Au->PCMBufSize);
	} else {
		ERROR_LOG(ME, "SceMp3InitArg ZERO");

Find:

	if (FindMp3Header(ctx, header, 1440) < 0)
		return hleDelayResult(hleLogWarning(ME, ERROR_AVCODEC_INVALID_DATA, "no header found"), "mp3 init", PARSE_DELAY_MS);

Replace:

	if (FindMp3Header(ctx, header, 1440) < 0)
		return hleDelayResult(hleLogWarning(ME, ERROR_AVCODEC_INVALID_DATA, "no header found"), "mp3 init", PARSE_DELAY_MS);

	ERROR_LOG(ME, "sceMp3Init HEADER: %08x", header);

What I'm trying to do is replicate the frame header to trigger sceMp3's behavior. I can send it appropriate audio data after that. Just looking for these two log messages for these mono mp3 files that play at 32kHz.

If mono is supported, I suspect we're supposed to output 44.1kHz single-channel mono, and are instead now outputting 23kHz stereo. This means we're losing audio quality and playing it slightly (but not significantly) faster than it should be played. But I can't confirm unless I can get the darn sceMp3 library to accept my mp3s...

In the trace, the overall structure of the init looks regular:

01:08:07 user_main - sceMp3ReserveMp3Handle 0x9FFD2B8 = 0x0
01:08:07 user_main - sceMp3GetInfoToAddStreamData 0x0, 0x8A615C4, 0x9FFD2DC, 0x9FFD2D8 = 0x0
01:08:07 user_main - sceMp3NotifyAddStreamData 0x0, 0x7230 = 0x0
01:08:07 user_main - sceMp3Init 0x0 = 0x0

I've tried frame headers including [ 0xFF, 0xFB, 0x18, 0x00 ] and [ 0xFF, 0xFB, 0x28, 0x00 ], which both represent 32kHz stereo at different bitrates. Then I tried [ 0xFF, 0xFB, 0x18, 0xC0 ] and [ 0xFF, 0xFB, 0x18, 0xC0 ] which represents stereo 32kHz at 32kbps and 64kbps. I'm wondering if it expects a different buffer size or something...

Even worse, this log says not MPEG v1, which my tests also can't pass, but maybe it's related:
https://report.ppsspp.org/logs/game/ULJM05998_1.01

-[Unknown]

Answer 36 · 2021-01-25T12:24:28.000Z

Modify log: https://gist.github.com/sum2012/553a2e087c4881874c2c69ff40ea0c25
1:04:093 user_main D[ME]: HLE\sceMp3.cpp:408 sceMp3Init(): channels=1, samplerate=32000Hz, bitrate=48kbps, layerBits=1 ,versionBits=3
20:59:656 user_main E[ME]: HLE\sceMp3.cpp:398 sceMp3Init HEADER: fffb38c0

Answer 37 · 2021-01-25T15:48:13.000Z

Thanks. I finally figured out it has to do with sdk version, 0x03090510 and newer are different. I'll dig into it more soon.

-[Unknown]

Answer 38 · 2021-01-27T21:31:13.000Z

The hack has removed in #13981 ,so that this issue can close