Robert Rostek
September 15th, 2008, 04:31 PM
Hello Gurus,
I need your input on a problem which is bugging me for several weeks now. i'll try to keep this posting as short as possible, but to avoid confusion, i have to explain some background details, so please bear with me if this post becomse lengthy :)
i am using a dj software (traktor) to play digital music. inside this dj software you can enter track information like artist, title, genre, comments, etc, and save these to the files "tags" (e.g. the id3-tag or vorbiscomment-tags, etc..).
see here for an example screenshot:
http://rrs.at/external/traktor_string.JPG
ok, now i'm developing a small tool that reads this information from the music files, and i got it working pretty well - artist, title, etc.. are all read correctly by my program. unfortunately, the dj software has some advanced information about the files, like cuepoints, additional comments, bpm count, lyrics, etc... which do not fit into standard id3-tags, as these kind of tags are not defined in the id3 standard.
so what the dj software does now, is to create it's own "custom tag", and save the information there, combined into one big, large text string.
so far, so good, but this "custom tag" seems to be encoded/encrypted/compressed/???? in some kind of way. it is not plaintext information.... see this example:
(this is what the dj software stores inside the custom tag, when i enter "THIS IS A TEST COMMENT" inside the comment2-field)
dlVHf&BABtAAAA4wlZi"AAC"AAAAllmZ"LAAAAAAAA`hGAjne0$8IAAAAAAA5FAAAA~4(F^aBAuWBAAAq6@b)tBAAAAAAA`BAAY4CAL"kA;B5F8M+hKAQAnB5FMcZ4K"pA=B5FUE,>L"mA#BMM#TCtKArHultBAAAAAAAAAAAA+O@WVwAAAAAAAAZF4($"xb)tiAAAAAAAAAAAAA3X[MP%AAAAAAAA_AAA1[BtHt0AwC5F95+hOAQAMC5FN/Z4O"5AyC5FmuvWOA6AcCUUN/BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
before i go more into detail, a small trip back to the previous version of this dj app - additional infos, e.g. cue points, were stored in custom tags in this format:
Tag Name: TraktorCuePoints
Tag Content: 3; 90.204082;n.n.|0; 110770.385488;n.n.|0; 250995.759637;C|
now, in the latest version of the app, they have removed these tags and put all advanced information inside the large string. my guess is, that the internal format will somehow be the same:
Identifier=Value;Identifier=Value;Identifier=Value;
... but encoded in some kind.
Release notes for the latest version read:
Unicode Support
- New: Unicode support provide a universal way of supporting
characters of any language in Traktor. This allows users working
in languages such as Japanese, Cyrillic, Hebrew etc. to use their
special characters anywhere for editing text in Traktor.
So, this is what i tried:
- base64 decoding
- base85 decoding
- rot13
- uuencode
- yyencode
- several other encoding mechanisms i found on the net
- i tried to do some 7-bit decoding (reading 7 bits, adding a zero, and converting it to a stream of bytes)
- gzip/unzip
i also mailed the manufacturer of the software - several times - but i never got any helpful response. i posted in another forum, but it turned into a discussion of how to read id3-tags (this is not the issue here)....
can anybody help me with this?
i will now provide some examples of this string, hopefulle someone detects an encoding scheme - i'm far too "noobish" in this area to proceed any further.
(first line is the string generated by the dj software, second line is the same string but all "A" removed, so you can read it better)
I first made a test: what happens when i stay in one field (e.g. comment2), and modify the string there.
Test 1: This happens when i enter "abcdabcdabcdabcdabcdabcdabcdabcdabcd" in the comment2 field:
dlVHD{BABtAAAA4wlZi"AAC"AAAAllmZ"LAAAAAAAA>mIAjne0$8IAAAAAAA5FAAAA~4(F3uBAuWBAAAq6@btiCAAAAAAAPDAA:CEtYAIB.IU)XLHtxASCFR;v+hMAyAMCVRVxCtO"wAOClR6yYLMAxAQC1RmuvWO"xASCFR;v+hMAyAMCVRVxCtMArHultBAAAAAAAAAAAA+O@WVwAAAAAAAAZF4($"xb)tiAAAAAAAAAAAAA3X[MP%AAAAAAAA_AAA1[BtHt0AwC5F95+hOAQAMC5FN/Z4O"5AyC5FmuvWOA6AcCUUN/BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtAAAA4w¼b?ËÒ?\
dlVHD{B Bt 4wlZi" C" llmZ"L >mI jne0$8I 5F ~4(F3uB uWB q6@btiC PD :CEtY IB.IU)XLHtx SCFR;v+hM y MCVRVxCtO"w OClR6yYLM x QC1RmuvWO"x SCFR;v+hM y MCVRVxCtM rHultB +O@WVw ZF4($"xb)ti 3X[MP% _ 1[BtHt0 wC5F95+hO Q MC5FN/Z4O"5 yC5FmuvWO 6 cCUUN/B t 4w¼b?ËÒ?\
Test 2: Now, this happens when i enter "aabcdabcdabcdabcdabcdabcdabcdabcdabcd" (notice the second "a" at the start)....
dlVHo|BABtAAAA4wlZi"AAC"AAAAllmZ"LAAAAAAAA;vIAjne0$8IAAAAAAA5FAAAA~4(FBwBAuWBAAAq6@bLoCAAAAAAAXDAA:CxWYAHB$Ie+5FI"YAIB.IU)XLHtxASCFR;v+hMAyAMCVRVxCtO"wAOClR6yYLMAxAQC1RmuvWO"xASCFR;v+hMAyA[dA8"FAAAAAAAAAAAAH7tB[MCAAAAAAAJVm"iBOU|CvBAAAAAAAAAAAA.ILNU,FAAAAAAAjHAABtOA0AcCUUBtXLP"5A$AwIuWuWItyAwCkUBtXLMA5AyCqS(,CtOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4w¼b?ËÒ?\
dlVHo|B Bt 4wlZi" C" llmZ"L ;vI jne0$8I 5F ~4(FBwB uWB q6@bLoC XD :CxWY HB$Ie+5FI"Y IB.IU)XLHtx SCFR;v+hM y MCVRVxCtO"w OClR6yYLM x QC1RmuvWO"x SCFR;v+hM y [d 8"F H7tB[MC JVm"iBOU|CvB .ILNU,F jH BtO 0 cCUUBtXLP"5 $ wIuWuWIty wCkUBtXLM 5 yCqS(,CtO 4w¼b?ËÒ?\
what i see here is that most of the beginning of the string stays the same, but from the middle on it changes completely, although the input string still consists of loops of "abcdabcd....." ... very strange?! it seems the additional "a" character somehow "shifted" the encoding algoryhtm to produce a different output.
Test 3: This happens, when i enter "axxxabcdabcdabcdabcdabcdabcdabcdabcd" - in other words, keep the positions of the "abcdabcd..." loop the same, just change the characters 2,3 and 4:
dlVHD{BABtAAAA4wlZi"AAC"AAAAllmZ"LAAAAAAAAksIAjne0$8IAAAAAAA5FAAAA~4(F3uBAuWBAAAq6@btiCAAAAAAAPDAA:CDAPA8A6CFR;v+hMAyAMCVRVxCtO"wAOClR6yYLMAxAQC1RmuvWO"xASCFR;v+hMAyAMCVRVxCtO"wAOClR6yBAS5!ERAAAAAAAAAAAAAQMzdBDAAAAAAAA}y"]PcSlUcEAAAAAAAAAAAC"T7KYNIAAAAAAC"KAAASKN/6yHt5A$AVJ@@AAvWYAgAJFvjp1F"OAQAMCEUN/YLP"5AyCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAçb??Ñ?\
dlVHD{B Bt 4wlZi" C" llmZ"L ksI jne0$8I 5F ~4(F3uB uWB q6@btiC PD :CD P 8 6CFR;v+hM y MCVRVxCtO"w OClR6yYLM x QC1RmuvWO"x SCFR;v+hM y MCVRVxCtO"w OClR6yB S5!ER QMzdBD }y"]PcSlUcE C"T7KYNI C"K SKN/6yHt5 $ VJ@@ vWY g JFvjp1F"O Q MCEUN/YLP"5 yC çb??Ñ?\
you notice the part "v+hMAyAMCVRVxCtO"wAOClR6yYLMAxAQC1RmuvWO"xASCFR;v+hMAyAMCVRVxCt..." beeing the same as in the first test?
what i can see here is that the encoding is some kind of "progressive" ... a character in the result stream depends on the previous characters. if the position of the "abcdabcd..." parts are the same, the result is the same. if the positions shift, the result turns to something completely different.
I need your input on a problem which is bugging me for several weeks now. i'll try to keep this posting as short as possible, but to avoid confusion, i have to explain some background details, so please bear with me if this post becomse lengthy :)
i am using a dj software (traktor) to play digital music. inside this dj software you can enter track information like artist, title, genre, comments, etc, and save these to the files "tags" (e.g. the id3-tag or vorbiscomment-tags, etc..).
see here for an example screenshot:
http://rrs.at/external/traktor_string.JPG
ok, now i'm developing a small tool that reads this information from the music files, and i got it working pretty well - artist, title, etc.. are all read correctly by my program. unfortunately, the dj software has some advanced information about the files, like cuepoints, additional comments, bpm count, lyrics, etc... which do not fit into standard id3-tags, as these kind of tags are not defined in the id3 standard.
so what the dj software does now, is to create it's own "custom tag", and save the information there, combined into one big, large text string.
so far, so good, but this "custom tag" seems to be encoded/encrypted/compressed/???? in some kind of way. it is not plaintext information.... see this example:
(this is what the dj software stores inside the custom tag, when i enter "THIS IS A TEST COMMENT" inside the comment2-field)
dlVHf&BABtAAAA4wlZi"AAC"AAAAllmZ"LAAAAAAAA`hGAjne0$8IAAAAAAA5FAAAA~4(F^aBAuWBAAAq6@b)tBAAAAAAA`BAAY4CAL"kA;B5F8M+hKAQAnB5FMcZ4K"pA=B5FUE,>L"mA#BMM#TCtKArHultBAAAAAAAAAAAA+O@WVwAAAAAAAAZF4($"xb)tiAAAAAAAAAAAAA3X[MP%AAAAAAAA_AAA1[BtHt0AwC5F95+hOAQAMC5FN/Z4O"5AyC5FmuvWOA6AcCUUN/BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
before i go more into detail, a small trip back to the previous version of this dj app - additional infos, e.g. cue points, were stored in custom tags in this format:
Tag Name: TraktorCuePoints
Tag Content: 3; 90.204082;n.n.|0; 110770.385488;n.n.|0; 250995.759637;C|
now, in the latest version of the app, they have removed these tags and put all advanced information inside the large string. my guess is, that the internal format will somehow be the same:
Identifier=Value;Identifier=Value;Identifier=Value;
... but encoded in some kind.
Release notes for the latest version read:
Unicode Support
- New: Unicode support provide a universal way of supporting
characters of any language in Traktor. This allows users working
in languages such as Japanese, Cyrillic, Hebrew etc. to use their
special characters anywhere for editing text in Traktor.
So, this is what i tried:
- base64 decoding
- base85 decoding
- rot13
- uuencode
- yyencode
- several other encoding mechanisms i found on the net
- i tried to do some 7-bit decoding (reading 7 bits, adding a zero, and converting it to a stream of bytes)
- gzip/unzip
i also mailed the manufacturer of the software - several times - but i never got any helpful response. i posted in another forum, but it turned into a discussion of how to read id3-tags (this is not the issue here)....
can anybody help me with this?
i will now provide some examples of this string, hopefulle someone detects an encoding scheme - i'm far too "noobish" in this area to proceed any further.
(first line is the string generated by the dj software, second line is the same string but all "A" removed, so you can read it better)
I first made a test: what happens when i stay in one field (e.g. comment2), and modify the string there.
Test 1: This happens when i enter "abcdabcdabcdabcdabcdabcdabcdabcdabcd" in the comment2 field:
dlVHD{BABtAAAA4wlZi"AAC"AAAAllmZ"LAAAAAAAA>mIAjne0$8IAAAAAAA5FAAAA~4(F3uBAuWBAAAq6@btiCAAAAAAAPDAA:CEtYAIB.IU)XLHtxASCFR;v+hMAyAMCVRVxCtO"wAOClR6yYLMAxAQC1RmuvWO"xASCFR;v+hMAyAMCVRVxCtMArHultBAAAAAAAAAAAA+O@WVwAAAAAAAAZF4($"xb)tiAAAAAAAAAAAAA3X[MP%AAAAAAAA_AAA1[BtHt0AwC5F95+hOAQAMC5FN/Z4O"5AyC5FmuvWOA6AcCUUN/BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAtAAAA4w¼b?ËÒ?\
dlVHD{B Bt 4wlZi" C" llmZ"L >mI jne0$8I 5F ~4(F3uB uWB q6@btiC PD :CEtY IB.IU)XLHtx SCFR;v+hM y MCVRVxCtO"w OClR6yYLM x QC1RmuvWO"x SCFR;v+hM y MCVRVxCtM rHultB +O@WVw ZF4($"xb)ti 3X[MP% _ 1[BtHt0 wC5F95+hO Q MC5FN/Z4O"5 yC5FmuvWO 6 cCUUN/B t 4w¼b?ËÒ?\
Test 2: Now, this happens when i enter "aabcdabcdabcdabcdabcdabcdabcdabcdabcd" (notice the second "a" at the start)....
dlVHo|BABtAAAA4wlZi"AAC"AAAAllmZ"LAAAAAAAA;vIAjne0$8IAAAAAAA5FAAAA~4(FBwBAuWBAAAq6@bLoCAAAAAAAXDAA:CxWYAHB$Ie+5FI"YAIB.IU)XLHtxASCFR;v+hMAyAMCVRVxCtO"wAOClR6yYLMAxAQC1RmuvWO"xASCFR;v+hMAyA[dA8"FAAAAAAAAAAAAH7tB[MCAAAAAAAJVm"iBOU|CvBAAAAAAAAAAAA.ILNU,FAAAAAAAjHAABtOA0AcCUUBtXLP"5A$AwIuWuWItyAwCkUBtXLMA5AyCqS(,CtOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4w¼b?ËÒ?\
dlVHo|B Bt 4wlZi" C" llmZ"L ;vI jne0$8I 5F ~4(FBwB uWB q6@bLoC XD :CxWY HB$Ie+5FI"Y IB.IU)XLHtx SCFR;v+hM y MCVRVxCtO"w OClR6yYLM x QC1RmuvWO"x SCFR;v+hM y [d 8"F H7tB[MC JVm"iBOU|CvB .ILNU,F jH BtO 0 cCUUBtXLP"5 $ wIuWuWIty wCkUBtXLM 5 yCqS(,CtO 4w¼b?ËÒ?\
what i see here is that most of the beginning of the string stays the same, but from the middle on it changes completely, although the input string still consists of loops of "abcdabcd....." ... very strange?! it seems the additional "a" character somehow "shifted" the encoding algoryhtm to produce a different output.
Test 3: This happens, when i enter "axxxabcdabcdabcdabcdabcdabcdabcdabcd" - in other words, keep the positions of the "abcdabcd..." loop the same, just change the characters 2,3 and 4:
dlVHD{BABtAAAA4wlZi"AAC"AAAAllmZ"LAAAAAAAAksIAjne0$8IAAAAAAA5FAAAA~4(F3uBAuWBAAAq6@btiCAAAAAAAPDAA:CDAPA8A6CFR;v+hMAyAMCVRVxCtO"wAOClR6yYLMAxAQC1RmuvWO"xASCFR;v+hMAyAMCVRVxCtO"wAOClR6yBAS5!ERAAAAAAAAAAAAAQMzdBDAAAAAAAA}y"]PcSlUcEAAAAAAAAAAAC"T7KYNIAAAAAAC"KAAASKN/6yHt5A$AVJ@@AAvWYAgAJFvjp1F"OAQAMCEUN/YLP"5AyCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAçb??Ñ?\
dlVHD{B Bt 4wlZi" C" llmZ"L ksI jne0$8I 5F ~4(F3uB uWB q6@btiC PD :CD P 8 6CFR;v+hM y MCVRVxCtO"w OClR6yYLM x QC1RmuvWO"x SCFR;v+hM y MCVRVxCtO"w OClR6yB S5!ER QMzdBD }y"]PcSlUcE C"T7KYNI C"K SKN/6yHt5 $ VJ@@ vWY g JFvjp1F"O Q MCEUN/YLP"5 yC çb??Ñ?\
you notice the part "v+hMAyAMCVRVxCtO"wAOClR6yYLMAxAQC1RmuvWO"xASCFR;v+hMAyAMCVRVxCt..." beeing the same as in the first test?
what i can see here is that the encoding is some kind of "progressive" ... a character in the result stream depends on the previous characters. if the position of the "abcdabcd..." parts are the same, the result is the same. if the positions shift, the result turns to something completely different.