Hanayaka Nari Wa ga Ichizoku strange MP3 mono voice

Question

Hanayaka Nari Wa ga Ichizoku strange MP3 mono voice

daniel229 opened this issue 10 years ago · 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)

Raven · Answer 1 · Sat Apr 05 2014 22:00:32 GMT+0800 (China Standard Time)

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

sum2012 · Answer 2 · Sun Apr 06 2014 01:19:13 GMT+0800 (China Standard Time)

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

Raven · Answer 3 · Sun Apr 06 2014 11:43:29 GMT+0800 (China Standard Time)

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

Unknown W. Brackets · Answer 4 · Sun Apr 06 2014 11:46:13 GMT+0800 (China Standard Time)

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

-[Unknown]

Raven · Answer 5 · Sun Apr 06 2014 11:52:15 GMT+0800 (China Standard Time)

Mostly likely .

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

sum2012 · Answer 6 · Sun Apr 06 2014 12:10:27 GMT+0800 (China Standard Time)

Force return 0x1200 still have strange MP3 voice

Raven · Answer 7 · Sun Apr 06 2014 12:15:49 GMT+0800 (China Standard Time)

Yep I tried as well probably need to change others elsewhere

Unknown W. Brackets · Answer 8 · Sun Apr 06 2014 12:28:57 GMT+0800 (China Standard Time)

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

-[Unknown]

kaienfr · Answer 9 · Sun Apr 06 2014 14:27:10 GMT+0800 (China Standard Time)

should be fixed here kaienfr@e9c605a

Raven · Answer 10 · Sun Apr 06 2014 14:41:49 GMT+0800 (China Standard Time)

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

kaienfr · Answer 11 · Sun Apr 06 2014 14:51:43 GMT+0800 (China Standard Time)

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.

daniel229 · Answer 12 · Sun Apr 06 2014 17:14:10 GMT+0800 (China Standard Time)

Great, sounds much better now.

Raven · Answer 13 · Sun Apr 06 2014 17:34:54 GMT+0800 (China Standard Time)

I see. thanks @kaienfr

kaienfr · Answer 14 · Sun Apr 06 2014 18:36:46 GMT+0800 (China Standard Time)

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...

Raven · Answer 15 · Tue Apr 15 2014 04:57:00 GMT+0800 (China Standard Time)

Probably this one can ve closed now?

Henrik Rydgård · Answer 16 · Tue Apr 15 2014 04:58:55 GMT+0800 (China Standard Time)

Can someone confirm this plays correctly now?

Raven · Answer 17 · Tue Apr 15 2014 05:07:33 GMT+0800 (China Standard Time)

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

daniel229 · Answer 18 · Tue Apr 15 2014 09:32:02 GMT+0800 (China Standard Time)

No,the voice is too fast.

kaienfr · Answer 19 · Tue Apr 15 2014 09:39:57 GMT+0800 (China Standard Time)

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

Raven · Answer 20 · Tue Apr 15 2014 10:14:49 GMT+0800 (China Standard Time)

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

kaienfr · Answer 21 · Tue Apr 15 2014 17:53:34 GMT+0800 (China Standard Time)

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.

Raven · Answer 22 · Tue Apr 15 2014 21:47:56 GMT+0800 (China Standard Time)

@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.

kaienfr · Answer 23 · Tue Apr 15 2014 22:13:17 GMT+0800 (China Standard Time)

@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...

thedax · Answer 24 · Thu Jul 31 2014 16:47:21 GMT+0800 (China Standard Time)

How is this one sounding now?

daniel229 · Answer 25 · Thu Jul 31 2014 17:12:01 GMT+0800 (China Standard Time)

Missing the last several words.

Unknown W. Brackets · Answer 26 · Tue Jan 19 2021 07:24:02 GMT+0800 (China Standard Time)

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]

sum2012 · Answer 27 · Tue Jan 19 2021 22:42:58 GMT+0800 (China Standard Time)

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.

sum2012 · Answer 28 · Wed Jan 20 2021 21:31:45 GMT+0800 (China Standard Time)

The sound is right in real psp

sum2012 · Answer 29 · Sun Jan 24 2021 04:24:16 GMT+0800 (China Standard Time)

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

Henrik Rydgård · Answer 30 · Sun Jan 24 2021 16:22:30 GMT+0800 (China Standard Time)

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

sum2012 · Answer 31 · Sun Jan 24 2021 17:21:48 GMT+0800 (China Standard Time)

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

sum2012 · Answer 32 · Sun Jan 24 2021 18:07:33 GMT+0800 (China Standard Time)

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

Unknown W. Brackets · Answer 33 · Sun Jan 24 2021 23:47:10 GMT+0800 (China Standard Time)

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]

sum2012 · Answer 34 · Mon Jan 25 2021 06:45:35 GMT+0800 (China Standard Time)

Yes, the audio sounds right now

Unknown W. Brackets · Answer 35 · Mon Jan 25 2021 15:13:26 GMT+0800 (China Standard Time)

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]

sum2012 · Answer 36 · Mon Jan 25 2021 20:24:28 GMT+0800 (China Standard Time)

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

Unknown W. Brackets · Answer 37 · Mon Jan 25 2021 23:48:13 GMT+0800 (China Standard Time)

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]

sum2012 · Answer 38 · Thu Jan 28 2021 05:31:13 GMT+0800 (China Standard Time)

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