Scott Wheeler [Thu, 12 Sep 2019 09:19:39 +0000 (11:19 +0200)]
Completely remove `StripAll` from the API
I'd imagined it being useful for calls to `strip()`, but it's not
actually used there since that's an OR-ed together set of flags
representing which tags to strip.
Call fflush() before ftruncate() to drop all buffered data (#914)
This avoids stale data presented to caller via a fread()
Current bug due to the buffered data can be seen in stripping mp3s of tags
f.strip(ID3v1);
f.strip(APE);
The ID3v1 tag sits at the end of file (strip calls ftruncate()) and the APE
strip performs a readFile() that would return the stream buffered/truncated data
and reinsert
setTrack()/setYear() accepts 0 to remove the tag as per
documentation/functionality across other tpyes (mp3/flac/...); m4a do not honour
this and instead sets the underlying value to 0.
Jörg Krause [Sun, 16 Jun 2019 13:33:52 +0000 (15:33 +0200)]
Drop CMAKE_SYSROOT from taglib-config
Commit d4c938cbc766ffb400c09efb9e696fce2537d81e is about fixing taglib-config for proper cross-compilation. The fix is right in principle, but wrong about adding `CMAKE_SYSROOT`. The correct prefix path should be set outside of the config file as some embedded Linux distros like OpenWrt or OpenEmbedded install with a different DESTDIR, and dependent packages see a different sysroot.
StefanBruens [Fri, 31 May 2019 11:21:16 +0000 (13:21 +0200)]
Respect atom type when converting rate tag (#896)
* Respect atom type when converting rate tag
TagLib prior to #818 (commit ff28cf276c60) read and wrote the "rate" tag as
text, and switched to reading it as integer value even when the atom class
is a text type. This breaks reading existing files, and can be avoided by
taking the atom type into account.
This fixes issue #885.
* Respect MP4::Item type when writing the rate tag
TagLib prior to #818 (commit ff28cf276c60) read and wrote the "rate" tag
as text, and switched to writing the integer value of the MP4::Item.
This breaks writing from applications which supply the value as
StringList, which was the previously implemented API. Applications using
an MP4::Item(UInt) are still supported without changes on the application
side.
This is the complementary writing part for issue #885.
Tim Malseed [Sun, 17 Mar 2019 13:22:19 +0000 (00:22 +1100)]
Update mp4properties.cpp (#893)
When parsing mp4 media header version 1 (mdhd) atoms, the timescale (unit) is parsed as a `LongLong` (8 bytes), but instead should be a `UInt` (4 bytes). This results in an incorrect timescale, and also pushes the offset of the duration (length) off by 4 bytes.
The end result being that the AudioProperties track length for mp4's with mdhd v1 comes back as 0.
Tim Malseed [Sun, 17 Mar 2019 13:20:43 +0000 (00:20 +1100)]
Minor fix for mp4 media header v0 minimum size check (#895)
Mp4 media header (mdhd) v0 atoms are a minimum of 8 bytes for size & type information, plus 24 bytes for remaining entries (`24 +8`) bytes in total, rather than (`24 + 4`).
See https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP40000939-CH204-25615
CVE-2018-11439 is caused by a failure to check the minimum length
of a ogg flac header. This header is detailed in full at:
https://xiph.org/flac/ogg_mapping.html. Added more strict checking
for entire header.
Stephen F. Booth [Sat, 30 Sep 2017 15:15:41 +0000 (10:15 -0500)]
Don't assume TDRC is an instance of TextIdentificationFrame (#831)
If TDRC is encrypted, FrameFactory::createFrame() returns UnknownFrame
which causes problems in rebuildAggregateFrames() when it is assumed
that TDRC is a TextIdentificationFrame
taglib: fix test build failure on powerpc/c++11 (#834)
powerpc is a platform with 'char' == 'unsigned char'.
As a result '-1' is not expressible in char and build fails as:
```
# '-funsigned-char' to force test build failure on other platforms
$ cmake .. -DBUILD_TESTS=YES -DCMAKE_CXX_FLAGS="-O2 -funsigned-char" -DCMAKE_C_FLAGS="-O2 -funsigned-char"
...
$ make check
tests/test_synchdata.cpp: In member function 'void TestID3v2SynchData::testToUIntBroken()':
tests/test_synchdata.cpp:78:33: error: narrowing conversion of '-1' from 'int' to 'char' inside { } [-Wnarrowing]
char data[] = { 0, 0, 0, -1 };
^
```
The fix is to expliticly cast -1 to 'char'.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
evpobr [Thu, 8 Jun 2017 13:59:14 +0000 (18:59 +0500)]
Fix WinRT configuring
Don't rely on _WIN32_WINNT value to enable WinRT support.
if _WIN32_WINNT is not set manually, it is defaulted to SDK version. So
if you use SDK > 8 you cannot use TagLib under Win7 and lower because of
CreateFile2 function dependency.
PLATFORM_WINRT option (OFF by default) was introduced to enable WinRT
build.
Related issues: https://github.com/Microsoft/vcpkg/issues/1240
Tsuda Kageyu [Tue, 7 Feb 2017 13:36:56 +0000 (22:36 +0900)]
Rename the functions 'isValidStream' to 'isSupported'.
The name 'isValidStream' is a little misleading because it doesn't check if the stream is really valid. Additionally, 'isSupported' can be naturally overloaded.
Tsuda Kageyu [Fri, 3 Feb 2017 08:52:27 +0000 (17:52 +0900)]
Enable FileRef to detect file types by the actual content of a stream.
FileRef doesn't work with ByteVectorStream as reported at #796, since ByteVectorStream is not associated with a file name and FileRef detects file types based on file extensions.
This commit makes FileRef to work with ByteVectorStream by enabling it to detect file types based on the actual content of a stream.
Scott Wheeler [Fri, 3 Feb 2017 13:56:02 +0000 (13:56 +0000)]
Ignore warnings about OSAtomicIncrement32Barrier
The warnings suggest moving to std::atomic functions, but those are only
available in C++11. It would be possible to switch to the C versions of
those functions, which are now provided in stdatoic.h (in C11), but
let's wait until we actually hit problems with this function and are a
few more OS versions into C11 headers being included by default.
Tsuda Kageyu [Fri, 27 Jan 2017 02:44:56 +0000 (11:44 +0900)]
Replace unicode.h/unicode.cpp by the UTF8-CPP library.
unicode.h/unicode.cpp are no longer maintained and incompatible with Debian's guideline.
UTF8-CPP is maintained on GitHub and published under the Boost Software License which is compatible with either LGPL or MPL and should go along with Debian's guideline.