Previous Page | Next Page

by DChronos at 10:16 PM EDT on March 24, 2009
To manakoAT:

1. I asked you some questions about figuring out the hex/byte value of the loop points back in July/August of LAST YEAR. I got what I needed to know to make them, for the most part, and left for the night when I had to go, but then contacted you once more wondering about something else and got no response, so I left. I figured it out on my own.

2. I don't know what the hell you're talking about with that table because, back when I pulled the music off the disk and asked you about it, since I was told you started working on it, you had no clue where those start/end/loop values were at on the disk, and you never said a damn thing about any table. You said they may be all together in some part, but didn't know where.

I told you how I was pulling the file apart and finding the loop points manually using a hex editor and an audio program I can loop with that shows the sample number it was at, and you never mentioned a word about anything different.

3. What the hell is your problem, you told me you were far from being done, was busy with something else, and had no plans to work on it anytime soon, and didn't care if I was doing them. You obviously care enough to take the time to come here to make a damn post about it like you somehow got a huge ass bruise to your ego from my post, insulting me for it.

I ended up too busy with my job and other things to finish them.

4. Since you don't seem to understand the concept that, when you have 2 channels with an interleave of 1024, it means you must take 2 1024 byte chunks for both left and right audio (2048 bytes for the full block), or you will CUT OFF one channel's audio data at the loop point and either cause a pop in that channel, or a reversal of the channel data, I decided to put together a nice little example with audio and explanations just to prove I know what the hell I'm talking about and that you might have it wrong.

Example.zip

Diagram.png

Set vgmstream to loop forever and play left and right genh files, read the text file for info on how I created them, check the code in the originals, and look at the diagram that explains why you will cut off the data if you don't loop properly. I figured this out myself and did this same exact test with left and right to figure out how it was read last year.

I was going to use this to take a few of the files which were supposed to be connected, but had a tiny gap of silence between the parts, and cut that silence for my own personal use.


When you learn all there is to know about something, knowing about it longer than someone else doesn't automatically make you more knowledgeable about it when the other person knows exactly the same info as you do.

edited 10:20 PM EDT March 24, 2009
by manakoAT at 6:26 AM EDT on March 25, 2009
As i said, rip it... i don't care about it!!!

If you want to show me something than upload a complete file instead of throwing pictures and splitted chunks into my way!

By the way, loopstart and loopend doesn't need to be set to a 1024 value, this is nonsense.
If the value isn't dividable by (interleave value * 2) at the loopend, you have a so-called "shortblock", which has absolutely nothing to do with wrong ripping, it's a feature which isn't implemented into the GENH meta and it won't be until it is really needed.

Just listened to my WA3 set for some hours, and i can't get in my head what you exactly want, i hear always my rip is a bad rip, but where are the facts? the png and the 2 splitted chunks showing me nothing...

could it be that you compare my files with the genh value?? if yes, keep in mind, genh holds all values as "samples", not as "bytes"!

and it's not against my ego what's going on here, i'm just a bit pissed that these threat hast 20 entries but no results, i have more important things to do than to poke around hours of hours in one of the 3000 sets.... if you're not satisfied, rip it, no one disallows that! :o)

MMX7: Somehow i can't download the MMX7 files, so if someone has uploaded them elsewhere, please share the link!!


edited 7:26 AM EDT March 25, 2009
by Knurek at 7:22 AM EDT on March 25, 2009
IIRC, VGMStream (and GENH by proxy) handles loop points by samples, not by bytes (hcs, anyone else, correct me if I'm wrong on this).

So the stuff you wrote about looppoints in WA3 is simple irrelevant (and the current rip, like I've been trying to say to you, plays fine).
by bxaimc at 3:26 PM EDT on March 25, 2009
Yea, what manakoAT and Knurek said......
by manakoAT at 4:56 PM EDT on March 25, 2009
Back to MMX7:

For now, you need to use GENH if you want to play them, GENH doesn't change a single byte in your files, you can extract them whenever you want with the correct CRC!

Header Skip: 40
Interleave: 32
Frequency: 48000
Channels: 2

If you have these values in the textboxes simply hit "Use File End", this calculates the LoopEnd.

For the LoopStart use the value at offset 0x18.

For example (B02.ADS) has the value 0x6A78, calculate this in decimal "27256"...

(27256 * 16) / 32 * 28 to get the samplecount for the LoopStart, that's all for now, works fine here! :o)

by DChronos at 6:57 PM EDT on March 25, 2009
First, manako, I was not making threats at you or saying your rips are bad, ok? I was only pointing out one thing I had come across which was related to what I was asking about way back in July, and as far as my experience with these files has shown, hasn't been wrong, but you're acting all pissed off for no real reason, seemingly because I dared to suggest you might have something wrong.

For MMX7, I already know how to play them thanks to bxaimc figuring out the header length. Plus, I already found an easier way to get the loop start which only involves multiplying by 16 and adding the header length, because the files state exactly what it is. Hell, actually, I found a way that's even easier than that, without having to multiply by 16. I can just convert the offset value I'm looking at which has always been the same after multiplying by 16, then add the header and I got the byte. It's worked just fine on all the files so far. Then I just enter the byte value and convert to samples and click the "use file end" button to get the end value.

In other words, I can create this set in an hour, all I'm doing right now is trying to find all the music that should be there. I found audio data for both English and Japanese voices in scenes, but I think the other audio is in the movie files, which are .pss, or elsewhere. Maybe some short jingles are in a single file. I didn't get time to look yesterday and was way too tired to bother with it.

Likewise, maybe Unknownfile knows where to find the rest. Either way, I'll be getting a preliminary rip up with what I got for now and get the rest as I go.

One last thing that I wish to learn more about is what the relation is between samples, sample size, bytes per sample, file size, all that junk, because still, when I look at sound data, I imagine it being split into channels and graphed into wave form as a continuous stream of sound data, and what data is read by the program is what matters. So again, I still don't see how having the program skip a chunk of the left channel's audio data that goes with the next chunk's right channel audio doesn't matter. Is there something I can read about this, because google isn't turning up anything useful for my limited time.
by Knurek at 7:19 PM EDT on March 25, 2009
It doesn't matter because there's a difference between how data is stored on disc and how it's stored by VGMStream before being sent to the sound card.

If it's interleaved on disc, meaning, say, 1024 bytes of left channel, 1024 bytes of right channel, repeat, VGMStream deinterleaves it to have 1 sample, repeat. And a sample can be mono/stereo/multiple channels and just about any data width (usually 16-bit).
by DChronos at 1:55 AM EDT on March 26, 2009
Got a couple more questions. Just to be certain about this:

When GENH makes a genh file, does it account for the header size you enter when it writes the loop start point to the file, as in, it automatically adds the header length to the loop start point? Only reason I'm wondering about this is because it changes the file end sample count if I change the header size and click the "use file end" button again, and takes the amount of the header out of the count for that number.

After making a ton of the different songs with and without the header added, I can't tell any difference, but I assume it doesn't and that I still need to add the header into the loop start point.

Second, what way do you tag these, is it still the same as the originals posted in the old stream sets in /bonus?
by Knurek at 3:48 AM EDT on March 26, 2009
You don't need to do anything with the loop point values, since GENH crator will do everything for you automatically. By adding a header you tell VGMStream that the real data starts at the provided offset in the file, so of course the sample count will decrease.
And since loop values are stored as sample number, not file position, the data you input (the location manakoAT mentioned for loop start)will be correct, with no manual fixing required.

And as to why you don't hear any difference with or without the header, think about it. Frequency of 48000 Hz means 48000 samples per second. Header is 40 bytes, each stereo sample in PS2 ADPMC takes, let's assume one byte per sample to ease things a bit. So that's 40 additional samples without proper header skip. That's 1/1200 of a second of additional playback, something you really won't hear.

Still, not skipping header isn't a good idea. Depending on the ADPCM format used, you can have all sorts of weird things happening (recently added Ridge Racer DS format had additional 0x10 bytes of header decoded at first, which resulted in weird volume fluctuations in some of the files. Adding proper header skip fixed them completely).

No tagging solution yet.

edited 3:51 AM EDT March 26, 2009
by manakoAT at 7:39 AM EDT on March 26, 2009
"HeaderSkip" is maybe not the best choice for the description, in fact it's a pointer to the bgm data (i'll change the name someday).

4096 bytes + HeaderSkip = Start of the real sample data (should be the first frame header).

And yes, the HeaderSkip was implemented to count only the samples for the sampledata so i need to substract it at first from the filesize and calculate the samplecount then.

edited 7:40 AM EDT March 26, 2009

Previous Page | Next Page
Go to Page 0 1 2 3

Search this thread

Show all threads

Reply to this thread:

User Name Tags:

bold: [b]bold[/b]
italics: [i]italics[/i]
emphasis: [em]emphasis[/em]
underline: [u]underline[/u]
small: [small]small[/small]
Link: [url=http://www.google.com]Link[/url]

[img=https://www.hcs64.com/images/mm1.png]
Password
Subject
Message

HCS Forum Index
Halley's Comet Software
forum source