Synthesia plays well midi file without any note off event? - midi

I have a .mid file - this one specifically. Appart from the header chunk here is the relevant part of the midi. The first track chunk contains only meta events and is described as
4D 54 72 6B 00 00 00 52 // Track chunk #1 info
00 FF 58 04 04 02 18 08 // Meta event
00 FF 59 02 00 00 // Meta event
00 FF 51 03 15 CC 5B // Meta event
81 88 70 FF 51 03 16 E3 60 // Meta event
81 70 FF 51 03 1A 28 6E // Meta event
81 70 FF 51 03 1C 9C 38 // Meta event
81 70 FF 51 03 1E 84 80 // Meta event
81 70 FF 51 03 20 B2 89 // Meta event
81 70 FF 51 03 23 36 6C // Meta event
81 70 FF 51 03 2B 98 B7 // Meta event
00 FF 2F 00 // Meta event. End of track #1
This is the second track chunk, wich contains only Note on events:
4D 54 72 6B 00 00 04 02 // Track chunk #2 info
00 FF 21 01 00 // Meta event
00 FF 03 1F 53 69 6E 66 6F 6E 69
61 20 66 72 6F 6D 20 4B 61 6E 74 61 74 61 20 23
31 30 36 20 2D 4A 53 20 // Meta event
00 C0 4A // Midi event
00 B0 07 7C // Midi event
00 B0 0A 52 // Midi event
00 B0 5B 4B // Midi event
96 40 90 4B 50 // Midi "Note on" event
81 63 4B 00 // Midi "Note on" event because of running status
... // No note offs event in this track chunk.
FF 2F 00 // Meta event. End of track #2
This is track #3:
4D 54 72 6B 00 00 03 27 // Track chunk #3 info
... // Some meta and non-note-on, non-note-off midi events
96 40 91 4B 50 // "Note on" event
81 63 4B 00 // Another "Note on" event
... // No note offs
FF 2F 00 // End of track #3
Track chunk #4, #5 and #6 have the same structure as #3; #7 contains two meta events only.
Note that every track chunk which doesn't contain only meta events starts with two Note on events, and no one of them contains a single Note off event.
But this is what synthesia (a midi player) sees when loading the file, just at the start of the song:
The structure of this midi would be a Note on event followed by a Note off event in the same track chunk, but this doesn't happen.
What's happening here?

96 40
90 4B 50 // Midi "Note on" event
81 63
4B 00 // Midi "Note on" event because of running status
^^
The MIDI specification says:
MIDI provides two roughly equivalent means of turning off a note (voice). A note may be turned off either by sending a Note-Off message for the same note number and channel, or by sending a Note-On message for that note and channel with a velocity value of zero. The advantage to using "Note-On at zero velocity" is that it can avoid sending additional status bytes when Running Status is employed.
Due to this efficiency, sending Note-On messages with velocity values of zero is the most commonly used method.

Related

Resolving contents of MiFare Ultralight NFC tag

I'm currently working with NFC/NDEF and I'm running into an issue where I'm unable to understand the data coming in. I have a general understanding of the NDEF standard and have looked over the MIFARE datasheet, so I'm able to pick out a few things, but there are a few bytes that are seemingly out of place and are puzzling me.
Here is the hexdump of the data on the tag, collected via nfc-mfultralight r:
00000000 04 02 2f a1 d2 11 5f 81 1d 48 00 00 e1 10 12 00 |../..._..H......|
00000010 01 03 a0 0c 34 03 1b 91 01 05 54 02 65 6e 68 69 |....4.....T.enhi|
00000020 11 01 05 54 02 65 6e 68 69 51 01 05 54 02 65 6e |...T.enhiQ..T.en|
00000030 68 69 fe 00 00 00 00 00 00 00 00 00 00 00 00 00 |hi..............|
I know the first 16 bytes (04 02 2f a1 d2 11 5f 81 1d 48 00 00 e1 10 12 00) are the NFC/MIFARE header (first 9 being the serial number/check bytes, 1 byte for internal, 2 for lock, and then final 4 are OTP bytes.)
Starting at byte 21 I can see the start of a TLV record with the Terminator TLV flag at the end (03 1b ... fe), indicating a record of NDEF type with length 27. This matches the length of the expected NDEF record.
However, I'm confused by bytes 16..20 (01 03 a0 0c 34). What are these?
It appears these are a part of the Lock Control TLV, a part of the NFC Type 2 Tag standard (pages 10-11).
The bytes are laid out as such:
0x01 - Lock Control TLV block name
0x03 - Length is 3 bytes
0xa0 - Encodes the position within the tag the lock area is at, composed of two nibbles:
0b0000 - Higher 4 bits represent the number of pages, while the lower 4 bits are the number of bytes
0b1100 - The number of bits used in the lock area.
0x0c - Indicates size in bits of the lock area
0x34 - Provides number of bytes in a page and the number of bytes each dynamic lock bit is able to lock.

Midi track meta event values which do not conform to the specification

Hi I have scraped a large number of midi files off the internet.
I am using them for training material to train a generative adversarial network. I find that many midi files conform to the midi standard but then I run into issues with midi meta events with values of FF11 and FF10 . I have looked up the midi specification from several sources and have never found midi meta events defined in this way. Here is the hex of a midi track event with some of the offending values:
4D 54 72 6B 00 00 1A 8D 00 FF 03 0D 47 75 69 74
61 72 20 44 41 44 47 41 44 00 FF 10 08 00 00 3E
39 37 32 2D 26 00 C0 19 00 C1 19 00 B0 65 00 00
B0 64 00 00 B0 06 02 00 B0 65 7F 00 B0 64 7F 00
E0 00 40 00 B1 65 00 00 B1 64 00 00 B1 06 02 00
B1 65 7F 00 B1 64 7F 00 E1 00 40 00 B0 0A 3F 00
B1 0A 3F 00 B0 5D 10 00 B0 5B 1E 00 B1 5D 10 00
B1 5B 1E 81 69 FF 11 01 00 00 90 3E 51 08 FF 11
I cant seem to find any information whatsoever on these values even though these midi files play over timidity and other midi player software perfectly. Can anyone point me to some information about them and what they mean? any help would be greatly , greatly appreciated. :-) resolving this issue would be a service to the miriad of people who are trying to use the python-midi library to train tensorflow models and this I am sure is only a fraction of the people who would be effected.
The SMF specification says:
As with chunks, future meta-events may be designed which may not be known to existing programs, so programs must properly ignore meta-events which they do not recognize, and indeed, should expect to see them.
I am not aware of any published extension that defines values 10h or 11h; it's likely that some sequencer uses these for its own purposes, and violated the specification by not using type 7F for that.

Inspecting binary over sockets

I'm using WireShark to inspect data sent/received over a web-socket, however, all I see is nonsense.
0000 1c 74 0d 7d 42 24 d8 5d e2 26 c1 7d 08 00 45 00 .t.}B$.].&.}..E.
0010 00 3c 75 4e 40 00 80 06 22 eb c0 a8 01 c0 4f 89 .<uN#...".....O.
0020 50 91 c4 f1 0f 78 72 e5 d0 f4 ea 5e 6e e2 50 18 P....xr....^n.P.
0030 00 40 91 b3 00 00 c2 8e 6d 06 87 95 7f 76 78 62 .#......m....vxb
0040 92 f9 54 2a 92 f9 b4 95 6c 06 ..T*....l.
I've seen this type of output before. The left is a line of binary, and the right is the decoded string (ASCII), right?
Is this data obfuscated/encrypted?
Is it possible to get cogent information from my socket?
Also, what do the [FIN] and [MASKED] flags mean?
If you copy and paste the data you supplied into a text file and append a line beginning with 0050 with nothing following it, you can then run text2pcap -a infile.txt outfile.pcap to convert the data to a pcap file that Wireshark can read and decode for you.
See the text2pcap man page for more information about this tool.
I have done this and the packet appears to just be a simple TCP segment. There is no [FIN] or [MASKED] flag, only PSH and ACK. For information about these TCP flags, refer to RFC 793, section 3.1, as well as the other RFC's mentioned at the top, which update this one.

Decoding an arbitrary block of NSData?

If I have an arbitrary block of NSData as a hex value, is there a way to determine what the object might have been before it was archived or serialized? I don't mind a few guess and check methods, but I need some pointers in the right direction.
I have an NSData object with some hex in it. What methods of NSData should I look at? Are there other classes to try as well
Don't want to scare people away from answering, but I have a file of game data which was likely encoded using a Cocoa Touch class. The data, when viewed in a hex editor, shows gibberish and a username, which leads me to suspect that it's an archived or encoded object of sorts. I have copied the hex from the hex editor into a sample project which I am using to try and unarchive the data.
I don't believe this is related to the 3d format, the file extension is arbitrary.
Here's the data. I'm hoping it doesn't get lost in translation:
'µköXN[ÎÀü÷h/F9ó9Vìñ°ceE¸z¶=Hmoshbermú«ó¼Ppù#ÝVÔ=4â®L,K;Êç;ASÀ&Ë÷ëÓ%È;Úf¬G}tmQ;µéüø_87´y©ã©!߶óQòAçÛl©âSG4S½3ýJת9äô¡wxiD²M¼ÏB]39øþ:óñ7ª¾÷躣È3Ï¢ÍEFÍ¢ª»r]BmÁ'Ò+åygÞÅQ?luó>÷ú¼è6¸|}[¼[¶Ñ¦g!\OÎÒJSE..pSß&_ÈEäø)6òëó¨¼2¶ð°æà`ï7Ë=Ã¥:cƧ=L4qG-"µ(ÐÝïß ÓãXkÀ4fzæ·p\ññT<tu¥Æ©;Ìn4£³Ï¢ÌFåG´
And the corresponding hex:
27 B5 6B F6 01 00 00 00 58 4E 5B CE C0 FC F7 68 2F 46 86 87 83 39 F3 39 9E 56 EC F1 B0 63 9E 65 45 B8 7A B6 3D 07 99 48 6D 6F 73 68 62 65 72 6D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90 86 FA 03 0E AB F3 BC 0B 50 70 F9 23 DD 87 56 03 D4 3D 34 90 E2 AE 4C 2C 94 9E 8E 15 4B 0C 83 8C 3B 03 CA E7 3B 1B 41 53 C0 26 04 CB F7 EB D3 25 C8 3B DA 66 8A AC 47 7D 8A 7F 74 6D 51 3B B5 19 E9 FC F8 5F 38 37 B4 11 0C 79 A9 12 E3 A9 21 DF B6 F3 51 F2 41 E7 DB 85 02 9F 6C A9 E2 53 47 1F 34 86 53 BD 33 FD 4A D7 AA 39 C3 A4 F4 A1 77 78 69 44 B2 4D BC CF 42 5D 33 39 F8 FE 97 3A 81 F3 F1 10 37 AA BE 86 91 F7 1F E8 83 BA A3 C8 33 CF 1D A2 CD 45 7F 46 1F CD A2 AA BB 1A 72 5D 42 02 6D C1 0F 27 D2 2B E5 0B 79 67 DE C5 1A 51 3F 14 6C 75 F3 3E F7 FA BC E8 36 8E B8 7C 02 1C 7D 01 00 92 8C 19 5B BC 5B B6 D1 A6 67 7F 21 5C 84 13 4F CE 0C D2 4A 53 19 82 45 1B 2E 2E 96 70 53 DF 26 5F C8 1C 45 8F E4 F8 29 36 F2 EB 9D 95 F3 A8 BC 32 B6 F0 B0 E6 91 98 1A E0 99 60 EF 37 CB 3D C3 A5 3A 63 0C C6 A7 3D 4C 34 71 47 2D 22 B5 28 D0 DD EF DF 09 D3 E3 58 6B C0 17 34 66 7A E6 B7 70 5C F1 F1 54 3C 74 94 75 A5 C6 15 A9 9E 14 3B CC 15 10 83 6E 34 A3 B3 CF 0F A2 9C CC 8E 46 8C E5 00 00 47 B4 17 05 00 00 00 00
If anyone cares to help figure this out it would be much appreciated.
If I have an arbitrary block of NSData as a hex value, is there a way to determine what the object might have been before it was archived or serialized?
Not really. That's about as 'trivial' as reading arbitrary files correctly without the use of a UTI, extension, MIME type. Of course, your program would also need to support reading of all those files/formats.
I don't mind a few guess and check methods, but I need some pointers in the right direction.
You need to narrow your problem/inputs down, if you don't want an impossibly difficult task.
I have an NSData object with some hex in it. What methods of NSData should I look at?
It's just a data blob of length bytes. It could represent anything -- if you don't know where it came from.
Are there other classes to try as well?
Perhaps you would start by saving all your data via NSCoder or another serializer/archiver which offers some introspection and support for you to enter your own information (which would be comparable to a UTI or MIME type).
Edit:
Don't want to scare people away from answering, but I have a file of game data which was likely encoded using a Cocoa Touch class. The data, when viewed in a hex editor, shows gibberish and a username, which leads me to suspect that it's an archived or encoded object of sorts. I have copied the hex from the hex editor into a sample project which I am using to try and unarchive the data.
Using these APIs, the data may be represented multiple ways. You're probably facing something within the domain of 1) a proprietary file format through 2) a keyed archive.
The latter is easier for nontrivial data representations. You would need to define any objc classes you do not have available when unarchived. In that case, a few sample representations would offer a rough outline of the data structures you will need (under conventional implementations). It could also be an archive similar to an NSDictionary, if the unarchiver is capable of opening it. This is a problem which is easier than with other langs, since archiving often falls back on keys and values mapped to members in Cocoa.
Edit2:
The file came from the Draw Something directory. It's called gamedata.i3d
(shrug)
Try using NSKeyedUnarchiver to read it. It's not uncommon to use just the standard Foundation containers like NSArray, NSDictionary, and NSString to store data, so you might get lucky. That obviously won't work if custom classes were involved, but it might be worth 15 minutes of your time to try it.

libzip corrupting PNG files when compressed on iPhone device, but not in Simulator

I've inherited a project that at some point creates a zip file, adds an XML file to the zip and then adds a number of PNG files to the same archive. All works fine on the simulator, but whenever I run the same code on the device itself the resulting png files are altered and unopenable when opened on my Mac.
They still appear to be png files, but the 'corrupt' export ones are slightly larger than the true files are, and hex dumps show the contents differ drastically. Headers are preserved though...
Original:
00000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 |.PNG........IHDR|
00000010 00 00 00 6d 00 00 00 75 08 06 00 00 00 44 7d 6f |...m...u.....D}o|
00000020 a0 00 00 00 19 74 45 58 74 53 6f 66 74 77 61 72 |?....tEXtSoftwar|
00000030 65 00 41 64 6f 62 65 20 49 6d 61 67 65 52 65 61 |e.Adobe ImageRea|
00000040 64 79 71 c9 65 3c 00 00 38 32 49 44 41 54 78 da |dyq?e<..82IDATx?|
Corrupt:
00000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 04 43 67 42 49 |.PNG........CgBI|
00000010 30 00 20 02 10 f3 44 7c 00 00 00 0d 49 48 44 52 |0. ..?D|....IHDR|
00000020 00 00 00 6d 00 00 00 75 08 06 00 00 00 44 7d 6f |...m...u.....D}o|
00000030 a0 00 00 00 19 74 45 58 74 53 6f 66 74 77 61 72 |?....tEXtSoftwar|
00000040 65 00 41 64 6f 62 65 20 49 6d 61 67 65 52 65 61 |e.Adobe ImageRea|
00000050 64 79 71 c9 65 3c 00 00 38 65 49 44 41 54 ed bd |dyq?e<..8eIDAT??|
(I appreciate a small chunk of the file header is not very helpful but the intention is to show that the corruption occurs within the PNG and not the ZIP itself.)
So I guess what I'm asking is whether anyone has experienced anything like this before? I just tried using the following wrapper http://www.flyblog.info/catprogramming/202.html and experienced the same issue, so am guessing its libzip itself causing the issue?
Does anyone have a simple, tried and tested method for adding files to a zip file on the Ipod that I can try and swap in?
If it helps, here is the code that creates the zip:
ZipArchive* zip = [[ZipArchive alloc] init];
BOOL ret = [zip CreateZipFile2: zipPath];
NSMutableSet *imageNames = [NSMutableSet set];
[curAlbum collectImageNames:imageNames];
for (NSString *imageName in imageNames) {
NSString *imagePath = [[NSBundle mainBundle] pathForResource:imageName ofType:#""];
NSLog(imagePath);
ret = [zip addFileToZip:imagePath newname:#"test.png"];
}
[zip release];
Any advice appreciated :-)
In addition to Noah's answer Xcode also compresses PNG files:
It might be worth setting COMPRESS_PNG_FILES = NO in the target info window.
When Xcode builds an application for the device, it alters any PNG resources, converting them to BGRA (as opposed to the usual RGBA) and premultiplying the alpha channel. There isn't a way to prevent this using any project settings that I know of; you might try giving the resources you include with the app an extension other than ".png" to see if Xcode then copies them without alteration.