If you are looking for the decompiler itself, visit https://github.com/jindrapetrik/jpexs-decompiler
NEW : We have got a new blog where we post some interesting SWF internals info.
List of issues#1013 Fail to save any SWF that was modified.
Author: 
Djamana
DjamanaDate created:
Type: bug
Visibility: Everybody
Assigned to:
State: closed 
> What steps will reproduce the problem?
1. Open some swf (Debug/Open test SWF as3.swf)
2. Edit a script (scripts/...TestMovie) [Edit] insert some <space> [save]
-> I'll marked Bold to show that it has changed
3. File/Save As Test.swf
> What is the expected output? What do you see instead?
-> there'll be just a Test.swf.tmp with 0 Bytes
remark:
A quicker way to check instead of save as is
'others/DoABC2()' -> it should marked bold
when I click it the screen on the right is NOT updated
=> if that happens save will definitively fail.
> What version of the product are you using? Is it "nightly build"? Which operating system
do you have?
Version: 6.0.1 Release date: 07/06/2015, 9:19 pm
on Win7 64 bit (with Java 8 32-bit)
> Please provide any additional information below. If the problem is related to a SWF
file, attach it here, otherwise we can't help you.
I got Netbeans + src and already located the buggy code:
it's here
jpexs-decompiler\libsrc\ffdec_lib\src\com\jpexs\decompiler\flash\SWFOutputStream.java
@Override
public void write(int b) throws IOException {
temp[tempPos] = b;
// cycle tempPos from 0 to 4
tempPos = ++tempPos % TEMPSIZE;
pos++;
// Compare b with the data from inputstream
int r = is.read();
if ((b & 0xff) != r) {
if (ignoreFirst <= 0) {
os.flush();
/*
boolean output = true;
if (output) {
System.out.println("Position: " + pos);
System.out.print("Last written:");...toHexString(temp[...])..
System.out.println("More expected:");....toHexString(is.read()..
System.out.println(Integer.toHexString(r) + " expected but " +
Integer.toHexString(b) + " found");
}
throw new NotSameException(pos);
*/
} else {
ignoreFirst--;
}
}
os.write(b);
}
}
The NotSameException will smash any upper save Tag/SWF or dumping function.
Why is there?
If there is made any change more than one byte 'NotSameException' will be raise
Seem to be some old debugging code.
OffTopic:
Made also some changes how to submit them for review?
It's my first time using Netbeans + Git.
Beside that I may also improve the german translation.
Yes, this is a debug/testing code, when you disable debugCopy you should not see this
problem. NotSameException is throwed by CopyOutputStream, and it is used only when
debugCopy is enabled.
CopyOutputStream is for testing the swf parser and composer. Normally it should not throw
this exception, but in some cases the composed data can be compatible but different from
the original.
So this is not a bug, the users should not use debugCopy (also should not use debug mode),
it is for the unit tests (not even for developers)...
However it is very interesting, that is fails with the test swfs (as2, as3.swf), because
unit test is checking them. I'll investigate it.
So please turn off debugCopy and debug mode... you can keep "show debug menu", then
let me know when you can reproduce this problem.
JPEXS: German translation: There is no update from krock sine 2013 sept, So I think it
would be great if Djamana improve it.
debugCopy is called "Debug recompile" in advanced settings.
Okay I reset the settings as well as "Debug recompile"- however ohoh an other bug's
approaching
private byte[] saveToByteArray() throws IOException {
...
sos.writeUI8(version);
sos.writeUI32(0); // placeholder for file length
sos.writeRECT(displayRect);
BUGGY >> sos.writeUI8(0);
BUGGY >> sos.writeUI8(frameRate);
SHOULD BE
sos.writeUI16(frameRate);
Else
writeUI16 cries out "Value is too large for UI8: 6144"
but this Exception never makes its way to be shown
...and again save will fail.
Okay but finally after fixing that glitch it Saving works again!
Are you sure that it is ok?
For example if the framerate is 24, then it should be 00 18 in the file... if you write it
as UI16, it will write 18 00
Could you pleaes attach your file?
I think you fix is wrong, so please be careful.. if you save the file with your modified
version of FFDec, the result can be corrupt. See the swf documentation:
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/swf/pdf/swf-file-form
at-spec.pdf
FrameRate UI16 Frame delay in 8.8 fixed number of frames per second
SWF 8 and later supports 16 bit 8.8 signed, fixed point numbers. The high 8 bits represent
the number before the decimal point, and the low 8 bits represent the number after the
decimal point. FIXED8 values are stored like 16 bit integers in the SWF file (using little
endian byte order) and must be byte aligned.
Oops sorry over read this FIXED 8.8 value thing.
And yesterday I was a little to enthusiastic when correcting that tippo
tmpFirstByetOfFrameRate to
tmpFirstByteOfFrameRate
and 'optimizing'
so I end up with:
frameCount = sis.readUI16("frameCount");
Okay I learned and undo that.
Finally I found this solution:
frameRate = (int) sis.readFIXED8("FrameRate");
...
sos.writeFIXED8(frameRate );
and discovered some minor bug in writeFIXED8
so 7.5 will get 0x0007 0080 instead of 0x0007 8000
I changed it like this:
/**
* Writes FIXED8 (Fixed point 8.8) value to the stream
*
* @param value FIXED8 value
* @throws IOException
*/
public void writeFIXED8(float value) throws IOException {
final int FIXED_POINT = 8;
final int ONE = 1 << FIXED_POINT;
int integerValue = 0xFFFF & (int) (value * ONE);
int beforePoint = integerValue >> FIXED_POINT;
int afterPoint = integerValue % ONE;
writeUI8( afterPoint );
writeUI8( beforePoint );
}
to make it correct and nice looking
just like:
public void writeFIXED(double value) throws IOException {
final int FIXED_POINT = 16;
final int ONE = 1 << FIXED_POINT;
long integerValue = 0xFFFFFFFF & (long) (value * ONE);
int beforePoint = (int) integerValue >> FIXED_POINT;
int afterPoint = (int) integerValue % ONE;
writeUI16( afterPoint );
writeUI16( beforePoint );
}
"and discovered some minor bug in writeFIXED8
so 7.5 will get 0x0007 0080 instead of 0x0007 8000"
FIXED8 is 2 bytes... how is it possible that it writes 0x0007 0080?
For me it seems to be ok. Please also check the testFIXEDandFIXED8 in SWFStreamTest.java
I changed the framerate to float number. Please check my commit:
https://github.com/jindrapetrik/jpexs-decompiler/commit/809091ea42cbbb8870359ab12ee98db337
ee876d
Wow nice I see you did it.
Also tried this but then decided to keep it at int since that ended up in kind of smaller
a'undertake'.
I would love to discuss somewhat more about 'sos.writeFIXED8' via github - instead of
posting code in here.
However before it's good to learn more about how to work with github...
Well yesterday I roughly finish the german translation for MainFrame_de.properties
and today I managed to upload them to git:
https://github.com/Djamana/jpexs-decompiler/commit/e117ba528f6d7b67b88876d11782f44e344f005
b
But yes some questions came up
#1 Wanna find out how to update/merge your last commit into the fork I created yesterday.
(instead of delete and reforking it)
...and #2 how to make and addition to a commit / joining two commits. Hmm read somewhat
about rebase / squish...
If ya like/have time we may also voice chat via Skype or better via Teamviewer <-so you
see what I see on the screen/ move the mouse / operate the keyboard via remote
Visibility: Everybody→Everybody
Is this issue solved? Can it be closed?
State: new→closed