Language…
19 users online: Alex No,  AmperSam,  Anorakun, Big Brawler, GiraffeKiller, Green, h.carrell, Hammerer, JikissGamer, LadiesMan217, MaffYuu, Mecke1990, Metal-Yoshi94, Ray Hamilton,  Segment1Zone2,  StayAtHomeStegosaurus, steelsburg, Tulip Time Scholarship Games, Zatara - Guests: 304 - Bots: 482
Users: 64,795 (2,369 active)
Latest user: mathew

IPS FLIPPER

since I can't post in C3 thread, I posted here.
Originally posted by Alcaro

Flips now refuses to create IPSes from files larger than 16MB. IPS has never worked above 16MB, but it previously changed things up to the 16MB limit (Lunar IPS did the same). But no more.


But since IPS does not limit the output size, i.e. people can have 16MB source file and whatever size of output file, maybe flips can just limit the original file size only?

Originally posted by Alcaro

I'm considering making BPS the only output format, and starting patch creation while asking for the output filename; this would make it a few seconds faster. If you like IPS, this would be a good time to speak up.

I still prefer IPS for files less than 16MB for compatibility.
Quote
IPS does not limit the output size

Huh, that's weird, I couldn't find anything in the IPS specification allowing output larger than 16MB plus 64KB.

Please upload an IPS that creates a file larger than that, and I'll figure out what it does and teach Flips how to recreate that.

Quote
I still prefer IPS for files less than 16MB for compatibility.

And I prefer BPS for everything. The size limit isn't the only advantage of BPS: They know which ROM they should be applied to, so you can't create a broken patch by using an unheadered clean ROM. And they're smaller.

As for compatibility, the more BPS patches exist, the more reason for patchers to add BPS support.
<blm> zsnes users are the flatearthers of emulation
Alcaro, I'm following up to our brief PM exchange about BPS metadata. I'm not sure if the manifest functionality will do what I'm looking for, but at least wanted to try it out and better understand it. Using the example you provided:
Code
flips -c clean.sfc my_hack.sfc my_hack.bps -m readme.txt


that turned into the following in my case:
Code
flips -c orig.sfc patch1.sfc flips-meta2.bps -m patchinfo.xml


where patchinfo.xml is an XML document that's compliant with BPS's metadata format. Eg.:
Code
<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <information>
    <title>Bahamut Lagoon</title>
<SNIP>


When running the above command *without* the -m option, it works fine. When including -m, I just get flips' usage information. I tried this instead, which seems to be closer:
Code
flips -c orig.sfc patch1.sfc flips-meta2.bps -mpatchinfo.xml


but in that case i got:
Code
The patch was created, but the manifest could not be read.


Am I missing something?

As to your other point about the usefulness of metadata, I can see where you're coming from, but from my perspective it's quite valuable. I like to keep my collection rather tidy, and for the ROMs that require patches I have a single BPS file that's dynamically applied at runtime. If I ever need to get details about the patch (ie., get look up the version number, source URL, special information, etc.) I can reference the metadata that I include in the BPS file. EG., if I wanted to look at the details of my Bahamut Lagoon patch:

Code
$ bpsview Bahamut\ Lagoon\ \(J\).bps | head -n 20
Title:  Bahamut Lagoon
Classification:  Translation
Language:  English
Description:  English Translation for Bahamut Lagoon
Author:  Tomato, Dark Force, Neill Corlett
Version:  1.3
Date:  2004-06-16
Url:  http://dejap.eludevisibility.org/bl.php

Instructions:
Bahamut Lagoon - Translation Notes by Tomato
---------------------------------------------------

  I. About
  --------
  I'm including a bunch of comments and notes about my translation of the
  text in Bahamut Lagoon for various kinds of people, including: fellow
  game translators, people who are curious about how I translated BL,
<SNIP>


When byuu first started pushing BPS I appreciated many of it's technical improvements of the competition, but the metadata aspect is what truly sold me on it. Since then, I've converted all other patches in my collection to BPS just so I can embed the relevant metadata.

Anyway, I understand I likely won't change your mind about it's usefulness as we all have our own methods for dealing with this stuff, but just wanted to point out there's a use case you maybe hadn't considered. If I can accomplish something similar using the manifest functionality in flips then I'll switch over in a heartbeat as there are several definite advantages over the version of bps I'm using. If not, I hope you'll give some thought to perhaps adding it in the future.

Thanks again for your work on this. It's an awesome little utility.
First of all, let me quote the PMs, so others can see what we're doing.
Originally posted by Alcaro
Originally posted by nitro322
Hi, Alcaro. I just discovered Floating IPS and am investigating it as an alternative to byuu's bps v02 utility for managing BPS patches (that older version is the last one I could get to reliably work from the CLI on Linux). So far it looks great, but I can't figure out one part.

bps/beat supports applying metadata to a patch, so I can embed the patch's README file or whatever else inside the BPS file. Does flips support embedding metadata?

I see that it has options relating to manifest files, but I can't quite figure out the syntax of who that's supposed to work, and from some brief research it appears that these manifest files are something specific to bsnes/higan rather than arbitrary metadata.

Apologies for the PM, but I didn't see any other recent discussions about Floating IPS or this topic in particular. Hoping you can point me in the right direction.

Thanks!

(The Flips thread is here, but PMs work too.)

The manifests are indeed not arbitrary text. Per the BPS specification, it's an XML document; in practice, it tells bsnes if it's HiROM, LoROM, or something else. (bsnes doesn't like sniffing the ROM header, or at least didn't when BPS was standardized. Yes, byuu is crazy.)

As such, all patchers assume it's intended for bsnes, not the user, and name the file accordingly. The BPS format doesn't contain any filename for the metadata, we can't do any better.

You can override that if you want (flips -c clean.sfc my_hack.sfc my_hack.bps -m readme.txt / flips -a my_hack.bps clean.sfc my_hack.sfc -m readme.txt), but then you need some way to tell the user that this specific manifest isn't for bsnes, and then you've got two readmes and might as well put everything in the first one.

That entire metadata field is silly. Without a proper specification, it's only confusing. Even if there is a bsnes manifest, it's better off being a separate file beside the bps.



Quote
I tried this instead, which seems to be closer:

yeah, I may have screwed up the syntax, didn't install Flips on this laptop and forgot how I defined the syntax. No space makes more sense.

If I get unclear file-not-found errors, I usually drop strace on it and check exactly what file it can't find. Maybe the argument parser is broken, wouldn't really surprise me; it's a pretty big mess and I didn't test it much, bad combination.

If strace doesn't reveal anything useful, or if it reveals a bug, you could try using the default filename: cp patchinfo.xml patch1.xml && flips -c orig.sfc patch1.sfc flips-meta2.bps -m

Quote
As to your other point about the usefulness of metadata, I can see where you're coming from, but from my perspective it's quite valuable.

My complaints are predicated on "without a proper specification". If there is an official standard I'm not aware of, that field is indeed useful, and I'll add an integrated bpsview. (If there's no official standard, I'm not gonna touch the de-facto anythings, too high risk someone skips <metadata>, or renames <information> to <info>, or inlines <title> to <information title="Bahamut Lagoon">, or something.)

Though broken -m is still a bug, with or without standardized metadata. I'll take a look today or tomorrow.
<blm> zsnes users are the flatearthers of emulation
Originally posted by Alcaro
My complaints are predicated on "without a proper specification". If there is an official standard I'm not aware of, that field is indeed useful, and I'll add an integrated bpsview. (If there's no official standard, I'm not gonna touch the de-facto anythings, too high risk someone skips <metadata>, or renames <information> to <info>, or inlines <title> to <information title="Bahamut Lagoon">, or something.)


Oh, I got you. No, unfortunately, I'm not aware of a defined standard as far as tag names and what not. Just this from the link you previously provided:

"Metadata stores an XML file in UTF-8 encoding. The string is not null-terminated. Because binary differencing has unlimited potential uses, there is no rigid standard for this data. XML is extensible, which is the whole point here.

"In the future, specifications for certain types of patches, eg SNES patches, may be defined."

and this from a specification document I found (pretty sure I saw this on an "official" source previously, but this current link looks like an archival copy that someone made):
https://gist.github.com/anonymous/bd56fc12003b3fde03f122d681828040

"Note that officially, metadata should be XML version 1.0 encoding UTF-8 data, and the metadata-size specifies the actual length. As in, there is no null-terminator after the metadata. However, the actual contents here are entirely domain-specific, so literally anything can go here and the patch will still be considered valid."

I'm at work now, but will try to do some debugging of the -m flag when I get home tonight and provide some more info about that.
Quote
pretty sure I saw this on an "official" source previously

Yeah, it disappeared off the internet. This backup is a bit more official. And here's the one I usually use, they seem functionally identical.

Quote
I'm at work now, but will try to do some debugging of the -m flag when I get home tonight and provide some more info about that.

Did that myself, then checked the source code.
Originally posted by flips.cpp:981 (may be elsewhere if you're on 1.31)
else if (!wcsncmp(argv[i], TEXT("-m"), wcslen(TEXT("-m"))))
{
manifestinfo.use=true;
manifestinfo.required=true;
manifestinfo.name=argv[i]+wcslen(TEXT("--m"));
}

--m. Nice typo, it discards the first character of the filename. Guess I only tested the long version, which isn't broken.

Available workarounds, pick your favorite:
- -m=foo.xml
- --manifest=foo.xml
- Replace --m with -m in source code and recompile; you're on Linux, you probably compiled already
- Pull latest dev version from github and recompile

and apparently the default name is foo.bml. also a bug, standards trump bsnes.

Since these bugs have been present for at least two years (probably five) with no reports, and there are plenty of workarounds, I'm gonna consider them low priority and not release a 1.32.


Now let's see how long until the Arch guys notice.

And to the other Arch guys: compare your pkgbuild to flips-git, some of your differences shouldn't be there.
<blm> zsnes users are the flatearthers of emulation
Well hot damn, using the (correct) manifest options to embed my XML metadata works perfectly. It appears to be embedded in the BPS file the same way bps/beat embeds metadata, so my bpsview function still works exactly the same. Loaded it up in mednafen and seems to work fine there as well. All good as far as I can tell.

Thanks a bunch, Alcaro. Happy to have a nicer alternative to bps/beat now.

Btw, one minor bug(?) report: this works fine:
Code
flips -c --exact --bps-delta orig.sfc patched.sfc patch1.bps --manifest=patchinfo.xml
The patch was created successfully!


However, this fails to embed the metadata:
Code
flips -c --exact --bps-delta-moremem orig.sfc patched.sfc patch2.bps --manifest=patchinfo.xml
The patch was created, but this patch format does not support manifests.


My understanding is that bps-delta-moremem and bps-delta should create create the same output, just one working more aggressively than the other. So, I think that error message should be updated to state that the patch *method* (or whatever) doesn't support manifests. or alternatively, assuming no technical limitations, just add support for embedding manifests with moremem. No biggie for me, just wanted to bring it to your attention.

Thanks again.


Edit: Sorry, did have one last question. The usage instructions state:
-mfilename or --manifest=filename: emit or insert a manifest file exactly here

Does that mean I can extract the manifest/metadata from an existing BPS file? If so, would you mind sharing the proper syntax for that as well? I've been playing around with it and haven't had much luck. bps/beat lacks this capability entirely, so this would be a welcome feature.
Yeah, that's a bug as well. Good catch, easy fix.

Maybe I should just remove that option entirely. Moremem is never more than ~3% faster than --bps-delta in my tests, and sometimes it's slower.
<blm> zsnes users are the flatearthers of emulation
damn, quick fix. Thanks. Did you see my question at the end about extracting the manifest? You replied so quickly (with the code fix as well) that I think you may have only seen the original post and not the edited version.
flips -I thing.bps -mthing.xml, or flips -I thing.bps -m for stdout, requires upgrade

...obvious follow up question: if you don't have anything to extract the meta, what is bpsview? Or if you do, why would you need two?

e: fixed derped html
<blm> zsnes users are the flatearthers of emulation
you're on a roll, Alcaro. I'll build the new version tonight and check it out.

bpsview is basically just a hack, using sed to look for data between <metadata> elements and transform the output into what I showed in the example. It doesn't give me a a full export, though, so whenever I update a patch I basically need to reconstruct the XML. Not difficult, but tedious. Being able to extract the complete metadata and write it to a file will save time.

Edit: So... I took a look at my bpsview function after typing the above to make sure that what I stated was accurate, and noticed something odd - I had an option to enable RAW output. I just tested that, redirecting the output to a file, and sure enough it gave me an exact copy of the raw metadata. Apparently I solved this problem a couple years ago and completely forgot about it.

Sigh. That would've probably saved me a good hour the last time I I did a bunch of patch updates.
I just spent a little while playing with the latest git version. Works great. Verified that -mfile.txt works, including manifest with --bps-delta-moremem works, and extracting with -I file.bps -minfo.xml works. The -I option, even without the metadata, is pretty interesting. Just to clarify, when using -I, do you intend to only output the first 3 lines of the metadata/manifest? I'm assuming so, but it seems like kind of an odd number, so just wanted to verify.

I know I'm pressing my luck now, but have you given any thought to adding UPS support, at least in terms of applying? I've only had to deal with them a handful of times, but it'd be really neat to have a single, well maintained and supported Linux CLI utility to handle all my patching needs. :-) I can understand if you don't want to get into maintaining the swiss army knife of patching utilities, but just thought I'd ask.

Oh, and just FYI, I got a number of warnings when building this with GCC 6.3.0. None fatal, and it looks like all of them are related to GTK. Compiled and runs perfectly fine, though. Just wanted to give you a heads up.
-I is for printing all kinds of information about the patch, most of which isn't from that metadata, and I'd rather not let the metadata flush the other stuff off the screen. If you want to pipe the metadata somewhere, -I -m. But yes, specifically 3 is indeed completely arbitrary. Maybe I should've used 4 instead.

UPS application already exists, but it's not advertised anywhere. Maybe I should add it to --help.

Those warnings are due to GTK deprecating all kinds of stuff between minor versions. Tell them to not do that. The only real fix is adding -Wno-deprecated to the makefile, or maybe setting some macro saying "I'm targeting GTK 3.10, shut up about your deprecated-since-3.12".

e: done. found a real warning too, neat
<blm> zsnes users are the flatearthers of emulation
heh, yeah, the deprecation stuff seems especially annoying with GTK. There's an emulator frontend that I used to really love called Gelide that I can't even get to compile anymore because of the GTK bits. Of course, it doesn't help that it's been effectively abandoned by its author.

I had no idea UPS already exists. That's pretty damn awesome. Any other hidden features? Don't supposed PPF or perhaps Ninja is already in there, huh? ;-)

Btw, messing around with this has inspired me to update all of my patches. Started with with SNES last night. I find it pretty amazing that the bps-delta algorithm is both faster than bps/beat AND results in smaller files. Granted, we're only talking kilobytes, but impressive nonetheless considering how efficient I already considered bps/beat to be.
how much do you expect of me

There are no secret formats other than UPS. There are some debug functions at the bottom of lib{i,b}ps.cpp, but you don't really need them.

I've poked the PPF and Ninja specs a little, PPF seems simple enough while Ninja is some kind of drunk mess. But neither of them seems common enough to worry about. (You may be able to convince me of the opposite.)


BPS is all about copying chunks of the input ROM to the output ROM, so the better you are at finding byte sequences similar to what you've already seen, the smaller patches.

beat is quite naive, it just compares the upcoming bytes with every position in the source ROM, which takes quite a while. In fact, it's too slow to be usable, so instead, it only checks every eighth byte. Sometimes one of the skipped positions would be better, so this gives slightly worse patches, but the speed improvements are worth it.

Flips, on the other hand, does some bizarre voodoo (I don't know how it works, but I do know how to use the results in Flips, and that's all I need) to find the matches much faster. It's so much faster I don't need the every-eighth trick, so I get the smaller patches too. It's documented in libbps-suf.cpp if you want the technical details.

But Flips is six times slower than Xdelta, and patches are about the same size. I have no idea what it does. Maybe it's cheating by not looking at the entire source file. Maybe I should rip apart its source code and steal its secrets.


And yes, GTK is silly too, maybe I should've used Qt. But on the other hand, weird extra build step (moc) and UTF-16 strings... sigh.
<blm> zsnes users are the flatearthers of emulation
Quote
where patchinfo.xml is an XML document that's compliant with BPS's metadata format. Eg.:


There is no official metadata format. Long ago, I was defining it as XML, but that's no longer the case.

And yes, I realize that's a problem, but ... no matter what I did, I would limit certain use cases, so I just don't define it anymore.

The only thing that's absolutely forbidden, is to use metadata to extend the patching format itself. That will break compatibility with other patchers that don't parse the metadata.

My recommendation these days is that metadata is in a human-readable format: XML/JSON works, but YAML/BML is much nicer. Plaintext is also okay. Markdown is nice, too. Not needing a special tool to read it is convenient and lets *any* patcher potentially display it.

Even if we tried to define an official format, it'd just be a mess. Look at MP3s. There's ID3v1/v2, APEv1/v2, Lyricsv3, etc.

Quote
The manifests are indeed not arbitrary text. Per the BPS specification, it's an XML document; in practice, it tells bsnes if it's HiROM, LoROM, or something else.


Noooooooooooooooooooo please don't ;_;

I know BPS is an agnostic format, and my own (lousy) patcher doesn't support it yet, but ... SNES/PCE/etc game BPS patches should always be made -sans- header. That's also the only way Snes9X and some versions of bsnes/higan will soft-patch them.

Quote
The BPS format doesn't contain any filename for the metadata, we can't do any better.


It wasn't meant to be a file you extract. I was afraid people would get cheeky and embed ZIP files in there and ... ugh. So that's why I didn't include a manifest filename field.

Quote
Yes, byuu is crazy.


Can confirm.

Quote
That entire metadata field is silly. Without a proper specification, it's only confusing. Even if there is a bsnes manifest, it's better off being a separate file beside the bps.


The idea of embedding a higan manifest was certainly a thing long ago, but is *very* much not the case today.

I have tried and failed to make some kind of universal standard format for describing the 100+ SNES PCB forms in existence, and I no longer try.

I generate manifests dynamically now instead of requiring them from users. So yeah, please don't embed bsnes/higan manifests in BPS patches ... the format is not stable and has changed not only details, but file formats (XML->BML).

Quote
Yeah, it disappeared off the internet.


I redid my site, and all the old documents were in raw HTML form. Now I am using a markdown-like syntax, but instead of converting all the old stuff, I just deleted it. Because I am terrible.

Haven't had the motivation to recreate the document since then.

Quote
UPS support


Sigh, I'm very sorry for inflicting that upon the world :(

Why can we never truly eradicate *anything* deprecated? ;_;

UPS is a trash garbage format that needs to die.

I mean, as long as it's just UPS patch application and not patch creation, I suppose it's pragmatic, which is Alcaro's cup of tea, so that's okay.

Quote
the bps-delta algorithm is both faster than bps/beat AND results in smaller files


Yeah, my algorithm has quadratic overhead, and to make it faster, I cut corners on the match comparison length, resulting in larger files.

beat's delta mode is awful. Flips' is vastly superior.

Quote
But Flips is six times slower than Xdelta, and patches are about the same size. I have no idea what it does. Maybe it's cheating by not looking at the entire source file. Maybe I should rip apart its source code and steal its secrets.


On its raw speed, no ideas.

But as an unrelated tangent on its patch sizes ... BPS vs Xdelta is tough.

BPS beats plain Xdelta, but not Xdelta -9. But Xdelta -9 is technically using compression. BPS often beats Xdelta -9 when you put the BPS file inside a 7za -9 archive. But if you put an Xdelta -9 patch inside a 7za -9 archive, then it tends to win on size once again.

But where BPS always wins is ... the BPS file format is 100x simpler than Xdelta's. Even if the patches are slightly larger, it's absolutely worth it.

Consider there are *zero* implementations of Xdelta other than the original author's. Then again, his default implementaiton doesn't suck, unlike the one from the BPS author.
expect? Nothing at all. But you've been so accommodating I can't help but ask. :-)

I can't really convince you of PPF or Ninja. In my (admittedly limited) experience PPF definitely seems more widely used, usually when dealing with patches for CD-ROM-based games, but I've only had to deal with them a handful of times. Probably about as much as UPS. Would be cool to have it built-in, but far from essential. Ninja, on the other, I think I've encountered exactly once. I found some PHP script to apply the patch, which is kind of scary, but it did work.

As a KDE user I'm much more partial to QT than GTK+, but I don't get much beyond scripting languages for programming, so I can't comment on the eccentricities of either. I'm sure GTK+ has it's advantages, though API compatibility across minor versions doesn't appear to be one of them. For stuff like this, though, I tend to favor the CLI. Much easier to deal with for bulk updates.
Originally posted by byuu
Long ago, I was defining it as XML, but that's no longer the case.

Oh, so the BPS spec wasn't final after all? Should've known you couldn't restrain yourself. mumble mumble

Quote
And yes, I realize that's a problem, but ... no matter what I did, I would limit certain use cases, so I just don't define it anymore.

I have no idea how defining the canonical representation for the bpsview output would limit anything.

If it's not machine readable (no, "pick one of these 500 machine readable formats" doesn't count), then no patcher can do better than showing the metadata as plaintext to the user, which leads to end users reading XML and nobody really wants that.

Quote
The only thing that's absolutely forbidden, is to use metadata to extend the patching format itself. That will break compatibility with other patchers that don't parse the metadata.

SNES/PCE/etc game BPS patches should always be made -sans- header.

What on earth does that have to do with anything either of us said

But while you're here, maybe you could convince this guy that headers are evil (at least throw an error), it's causing trouble

As much as I want to remove that ugly special case from Flips, I can't and won't until we can declare headers dead (at least within SMW), aka when *that guy* stops being a blueberry.

Quote
Why can we never truly eradicate *anything* deprecated? ;_;

hi i want run bsne's on window sxp why it not work halp

Quote
The idea of embedding a higan manifest was certainly a thing long ago, but is *very* much not the case today.

It was the case when the standard was published, and as we all know, we can't eradicate what should die.

Quote
Sigh, I'm very sorry for inflicting that upon the world :(

It's better than IPS.

...I think.

Quote
BPS beats plain Xdelta, but not Xdelta -9. But Xdelta -9 is technically using compression. BPS often beats Xdelta -9 when you put the BPS file inside a 7za -9 archive.

There is one thing I want to test:

Take a BPS patch and disassemble it into a sequence of SourceCopy/TargetRead/etc instructions. Translate to the closest Xdelta equivalent. What is the resulting filesize, compared to native?

Quote
Consider there are *zero* implementations of Xdelta other than the original author's.

I see your facts and I raise you some alternative facts

Originally posted by nitro322
expect? Nothing at all. But you've been so accommodating I can't help but ask. :-)

are you testing my patience, mortal

Quote
In my (admittedly limited) experience PPF definitely seems more widely used, usually when dealing with patches for CD-ROM-based games, but I've only had to deal with them a handful of times. Probably about as much as UPS. Would be cool to have it built-in, but far from essential.

I'll promise you this: If I find a PPF I want to play, I will not do that until I can apply it with Flips.

...but I doubt that'll happen.

Quote
Ninja, on the other, I think I've encountered exactly once. I found some PHP script to apply the patch, which is kind of scary, but it did work.

Yeah, I believe that's the reference patcher.

A desktop app written in PHP. Just ... why.

Quote
As a KDE user I'm much more partial to QT than GTK+, but I don't get much beyond scripting languages for programming, so I can't comment on the eccentricities of either. I'm sure GTK+ has it's advantages, though API compatibility across minor versions doesn't appear to be one of them. For stuff like this, though, I tend to favor the CLI. Much easier to deal with for bulk updates.

I believe it uses less memory. And less C++, some people hate that.

But the devs seem perpetually drunk. Did you see the GTK 4 is not 4.0 warble?

(fun fact: you get the most useless command line feature if you compile Flips with GTK: You can use http://example.com/derp.bps as source file!)
<blm> zsnes users are the flatearthers of emulation
Originally posted by byuu
My recommendation these days is that metadata is in a human-readable format: XML/JSON works, but YAML/BML is much nicer. Plaintext is also okay. Markdown is nice, too. Not needing a special tool to read it is convenient and lets *any* patcher potentially display it.

Even if we tried to define an official format, it'd just be a mess. Look at MP3s. There's ID3v1/v2, APEv1/v2, Lyricsv3, etc.


byuu! Nice to see you. I didn't realize you still frequented these forums.

I don't have too much to add to most of your comments (it's generally beyond me), but as for the above, while ID3 is indeed a mess, I've found VorbisComment approach a good way to address this. It establishes a standard format with recommended field names, but allows users to add any additional fields they would like. If you did want to consider further standardization of BPS, I think that might be a good approach - you can have a core set of standard fields for the most common info, and allow users to extend it beyond that as they fit, provided they stay within the general structure.

https://wiki.xiph.org/VorbisComment
https://xiph.org/vorbis/doc/v-comment.html

Originally posted by byuu
Consider there are *zero* implementations of Xdelta other than the original author's. Then again, his default implementaiton doesn't suck, unlike the one from the BPS author.


I know that's just being self-deprecating, but I've been using bps v02 for years now quite happily. I couldn't get beat/v03 to work right in CLI mode, though, so when I found flips, which appears to be more actively developed AND a little more efficient to boot, I decided to switch. I'm very appreciative of the work you've done on both the BPS format and utility, though.

Originally posted by Alcaro
I'll promise you this: If I find a PPF I want to play, I will not do that until I can apply it with Flips.


Well... Dragon Quest V for PS2 is in PPF, though I guess that's less useful since the DS version was released. Ys IV English translation for PC Engine CD is PPF. I know I ran across it for a few others, but I'm drawing a blank on them now.

Originally posted by Alcaro
A desktop app written in PHP. Just ... why.


I'm not defending it because I recognize the absurdity, but in fairness I've done this myself before. In my case I primarily know shell scripting and PHP. I had a situation where I couldn't get everything I needed out of a shell script, so switched to PHP. It worked, and still use that script about a decade later, but I'm not proud of it.

Originally posted by Alcaro
But the devs seem perpetually drunk. Did you see the GTK 4 is not 4.0 warble?


Just looked that up. News to me, but as per your drunk comment, I tend to expect silliness from them, so I generally don't pay much attention. They (+GNOME) lost me long ago with their "users are stupid and we need to protect them from themselves" approach to everything.
hey, you edited your post while I was busy replying.

Originally posted by byuu
Even if we tried to define an official format, it'd just be a mess. Look at MP3s. There's ID3v1/v2, APEv1/v2, Lyricsv3, etc.

I'm pretty sure none of those are official, and that's exactly why it's such a mess. If one single format is standardized, I believe everyone (to within experimental error) will use that.

And even if we don't, one will eventually come out on top, like ID3v2 is the only one I ever see in mp3s.

I believe xdelta contains metadata as well; I'm pretty sure I saw an xdelta patch tell me the source filename.

Quote
It wasn't meant to be a file you extract. I was afraid people would get cheeky and embed ZIP files in there and ... ugh. So that's why I didn't include a manifest filename field.

It's a file when you insert it, and becomes one when applying, extracting without applying is a pretty obvious idea. Way more than any reasons to not allow that, and way more obvious than using the checksum to identify the source ROM.

Quote
Quote
the bps-delta algorithm is both faster than bps/beat AND results in smaller files

Yeah, my algorithm has quadratic overhead, and to make it faster, I cut corners on the match comparison length, resulting in larger files.

beat's delta mode is awful. Flips' is vastly superior.

I did fiddle a bit with the heuristics, Flips v1.21 managed to beat yours (both speed and size) even with the same basic algorithm. I don't remember the details, and I don't have the source code anywhere, but the numbers remain.

Originally posted by nitro322
byuu! Nice to see you. I didn't realize you still frequented these forums.

I'm still not completely sure why he keeps popping into random threads to apologize for stuff that's not his fault.

But sure, why not, the more the merrier.

Quote
I've been using bps v02 for years now quite happily

If you don't know anything better exists, what you have is perfectly sufficient. For example internet speed; if you've always had 1MB/s, that's enough, you just don't do anything that needs more. But if you get upgraded to 10MB/s, visiting your relatives and their 1MB/s is now slow as hell.

Same goes for bps/beat vs flips. With beat, you just don't create patches larger than 4-8MB, it's too slow. With Flips, 64MB is easy, and beat is for grandmothers.

Quote
flips appears to be more actively developed

Maybe beat is finished, there is a point where there are no more plausible features to add. I haven't had anything to do on Flips since January.

...but on the other hand, fixing the crippling performance issues would be a quite plausible feature.

Quote
I'm very appreciative of the work you've done on both the BPS format and utility, though.

i'm more important

Quote
Well... Dragon Quest V for PS2 is in PPF, though I guess that's less useful since the DS version was released. Ys IV English translation for PC Engine CD is PPF. I know I ran across it for a few others, but I'm drawing a blank on them now.

That'd be a quite convincing argument if I was into those series. I've heard about them, but never looked closer, I'm not even sure what genre they are.

Not sure if PS2 emulation works properly yet, either.

Quote
I had a situation where I couldn't get everything I needed out of a shell script, so switched to PHP.

I once made an IRC bot in PHP.

Some simple math operation (999999**999999 I think?) turned out to be the infinite loop of bot slaying.

I rewrote it in C++.

Quote
"users are stupid and we need to protect them from themselves"

I want to know how they manage to not insult themselves while using that.

GTK+ has way too much "vision". Low-level libraries shouldn't have any of that, they should care only about their users. Yes, GNOME is a user, but far from the only one.

Same goes for glibc, merge execveat and memfd_create already, all you're accomplishing is making people create their own wrappers.
<blm> zsnes users are the flatearthers of emulation