Closed GoogleCodeExporter closed 8 years ago
- FIX: Removed debug code from MPEG::__contruct which output the number of
invalid frames.
- NEW: ID3v2::addFrame now accepts a string for $frame which specifies the ID
of the frame to add. If the frame
exists, its imported, constructed and used.
Original comment by but...@gmail.com
on 29 Jul 2008 at 12:59
Attachments:
Original comment by svollbehr
on 29 Jul 2008 at 7:04
Regarding to some of your fixes to Transform class, I think the PHP
documentation
also suggests to use the method you have changed the code to. However,
internally PHP
uses signed integers, which means using unpack("V*") with a big integer would
result
to buffer overflow and produce -1 or similar. Hence my solution unpacks high
and low
bytes separately and then uses aritmetic operation that implicitly converts the
resulting integer into float where it can fit the result (either that or using
sprintf, and of which I thought the former was neater).
I'm not sure if this causes some problems with 64-bit machines (I'm developing
on a
32-bit machine), though, if that is the reason you needed to change the code
there.
The reason it might work with you is that you are probably working with x64
where the
integer size is 8 bytes.
In 64-bit environment the PHP integer size might (or might not) be double that
of
32-bit environments and would result the expected value with unpack("V*") for
example.
One could perhaps add a check whether the integer size is 4 bytes and use the
current
way only then, and otherwise just plain unpack(..). I was not aware of a
PHP_INT_SIZE
before you introduced it in your patch.
Original comment by svollbehr
on 29 Jul 2008 at 9:06
Hey Sven,
Glad your finding use with my changes. Yes its okay to include my name and
email in the class documentation.
Regarding the Transform changes. I develop on a 32bit machine as well, so I'm
in the same boat as you, hence why I
commented out the 64bit tests if run on a 32bit machine. Why PHP doesn't
support > machine size integers I don't know. eg.
Automatically fall back on a Big-Int library if integer goes over the machine
limit.
The reason I moved away from your floating point idea is precision and so PHP
treats them as integers, allowing for bit
masking/manipulation. It also ensures what is read is exactly what is written
back (important for unit tests).
The signed integer problem isn't really a problem at all. Unless you try and
perform arithmetic on the values returned. For
example, an unsigned 0xffffffff is exactly the same in memory as a signed
-0x7fffffff. You can always perform a sprintf("%u")
when displaying the results to the user if the value should be unsigned.
I think the idea of falling back to floating point for 64bit integers is okay
if the PHP_INT_SIZE < 8, but I think you should try and
keep them as integers as much as possible (if supported). You will have to
check all code that uses the 64bit values and ensure
the operations it performs on them is sane for floating point numbers and that
you don't lose precision during these operations.
Another idea could be to fall back on a bit int library for php. I'm sure there
are a couple out there though I haven't looked into
this yet.
All the best,
Ryan
Original comment by but...@gmail.com
on 30 Jul 2008 at 1:47
Another thing, instead of removing UTF16LE altogether from ID3_Encoding, it
could
perhaps be usefull to make it produce UTF16 with LE BOM. That is kind of the
idea
behind the current code although the current way of being an alias to UTF16 is
errorneus. That way one could write texts in all possible ways: UTF-16 LE/BE w/
and
w/o BOM. Does it make sense?
Original comment by svollbehr
on 30 Jul 2008 at 10:44
Hey Sven,
The reason for the removal of the UTF-16LE was so that the code documented the
spec, which is defined as:
$00 ISO-8859-1 [ISO-8859-1]. Terminated with $00.
$01 UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All
strings in the same frame SHALL have the same byteorder.
Terminated with $00 00.
$02 UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM.
Terminated with $00 00.
$03 UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00.
This means the possible combinations of UTF-16 are: UTF-16BE w/o BOM, UTF-16BE
w/ BOM and UTF-16LE w/ BOM. When
writing UTF-16 with a BOM, it wouldn't make sense to write in anything other
than the current machines architecture as
you'd get a performance hit due to byte-swapping. Hence why I didn't think it'd
be worth keeping the LE concept.
To have UTF-16LE you'll have to introduce a new value $04 and translate it to
UTF-16 ($01) with a forced BOM of LE in every
frame that using encoding. Possible but only makes sense during writing, not
reading. (eg. You'll never read a $04).
The decision is totally up to you as its your library, though I'm enjoying
discussing the options with you. :o)
Thanks and all the best,
Ryan
Original comment by but...@gmail.com
on 30 Jul 2008 at 1:17
Original comment by svollbehr
on 30 Jul 2008 at 7:59
Thank you so much Ryan for all the effort you have taken to make this library
better!
I have now made the changes to the library code. I appreciate the new test
classes
and the implementations of some of the remaining frames, not to mention the
MPEG code
you have provided. Here is a list of changes made to the library:
o Code samples have now been added as part of the on-line documentation.
o Transform class now uses PHP_INT_SIZE to use the workarounds only when actually
needed (ie only on 32-bit machines)
o Unicode (UTF-16) strings are now handled correctly and all tests have been
revised accordingly.
o All fixed defects have been applied.
o Almost all new features or changes have been applied too.
Some changes I have left aside as I thought they were inappropriate or couldn't
see
the reason to add the code. Among these were the following changes.
o The removal of UTF-16LE, which has been kept and instead made it work as expected
o Removal of the abstract keyword from AbstractText and AbstractLink as these
classes should be tested with mock objects instead.
o Addition of all the new constants such as channelType and volumeAdjustment. The
idea was accepted, just that these were added as real constants instead of
static
strings.
o The idea of adding a frame with a string name of the frame. One could simply call
$id3-><frame> (eg $id3->tit2->text = ...) to add a new frame. When a frame is
accessed with a shorthand call like that, a new frame will be created and added
to
the tag should the tag not contain one already. However, there was a bug in this
functionality in the 1.4 version that has now been fixed.
The support for determining the MPEG file play duration has been separated to
another
issue. I need to think more of what would be the best name for the class and
what
kind of an interface should it have (the problem covers two standards, and the
source
you refer to is informal). Determining the play duration of an mpeg video would
be
usefull too. Docs must be written too before it can be added to the library. I
just
loved the Twiddling class, I will add it together with the MPEG related files.
Original comment by svollbehr
on 9 Aug 2008 at 5:17
Original comment by svollbehr
on 20 Feb 2009 at 9:09
Issue 9 has been merged into this issue.
Original comment by svollbehr
on 20 Feb 2009 at 9:18
Issue 10 has been merged into this issue.
Original comment by svollbehr
on 20 Feb 2009 at 9:18
Original issue reported on code.google.com by
but...@gmail.com
on 27 Jul 2008 at 3:48Attachments: