If an M4A file contains trailing garbage (e.g. an APE tag at the
end of the file), it was considered invalid since [e21640b].
It is important to make sure that atoms which affect modifications
written by TagLib are valid, otherwise the file might be damaged.
However, in cases where invalid atoms do not affect modifications
(which are only done inside the root level "moov" and "moof"
containers), they can be safely ignored.
This commit allows trailing garbage in M4A files as it is also
accepted in MP3, WAV and DSF files.
Many shadowFunction, some useStlAlgorithm, and others.
cppcheck --enable=all --inline-suppr \
--suppress=noExplicitConstructor --suppress=unusedFunction \
--suppress=missingIncludeSystem --project=compile_commands.json
When calling setAutoDelete() on the implicitly shared copy of a list,
also auto-deletion of the original container was modified because
it was not detached. On the other hand, detach() was called by some
methods getting an Iterator parameter, which can lead to modification
of other implicitly shared copies but not the object is was called on.
This happens when the method is called on a not-already-detached
container, which is normally not the case because the container is
detached when the iterator is taken (e.g. calling begin()).
In such methods detach() cannot be called, and the client must
make sure that the iterator is taken after making an implicit copy.
This will NOT work:
List<int> l1 = { 1 };
auto it = l1.begin();
List<int> l2 = l1;
l1.erase(it);
This will modify both l1 and l2. The second and the third lines
must be swapped so that l1.begin() will detach l1 from l2.
The frames in a frameList() copy were not deleted because it had the
autoDelete property active. However, removed frames cannot be auto
deleted. Using setAutoDelete() affects the source of the copy, which has
to be investigated further.
Because the main extension point of FrameFactory was using a protected
Frame subclass, it was not really possible to implement a custom frame
factory. Existing Frame subclasses also show that access to the frame
header might be needed when implementing a Frame subclass.
This will install a <libdir>/cmake/taglib/ folder with CMake
configuration, so that users can simply use
find_package(TagLib)
add_executable(myproject ...)
target_link_libraries(myproject TagLib::tag)
A frame with ID "APIC" is not guaranteed to be an AttachedPictureFrame,
it can also be an invalid UnknownFrame with ID "APIC". Check the types
of the frames before accessing them.
* Use ID3v2::FrameFactory also for WAV and DSDIFF
* Apply suggestions from code review
Co-authored-by: Kevin André <hyperquantum@gmail.com>
---------
Co-authored-by: Kevin André <hyperquantum@gmail.com>
With specially crafted WAV files having the "id3 " chunk as the
only valid chunk, when trying to write the tags, the existing
"id3 " chunk is removed, and then vector::front() is called on
the now empty chunks vector.
Now it is checked if the vector is empty to avoid the crash.
Detect ADTS MPEG header to use it also for AAC.
The test file empty1s.aac was generated using
ffmpeg -f lavfi -i anullsrc=r=11025:cl=mono -t 1 -acodec aac empty1s.aac
---------
Co-authored-by: Nick Shaforostov <mshaforostov@airmusictech.com>
Co-authored-by: Urs Fleisch <ufleisch@users.sourceforge.net>
The padding was wrong, 8 seconds were displayed as 0:80 instead of 0:08.
Also make the output of tagreader and tagreader_c the same, including
the encoding, which was still ISO-8859-1 for std::ostream.
In order to achieve this, the TagLib_File type of the C bindings is now
a FileRef and no longer a File. The support for the .oga extension has been
ported to FileRef(), so that taglib_file_new() should still behave the
same, but additionally also support content based file type detection.
Use of FileRef::file() is discouraged, but was necessary to access the
properties. It was also not clear whether to access the properties via
tag() or file(). With the property methods on FileRef, it should become
the "simple usage" interface it was meant to be.
As the destructor was the only virtual method on FileRef, it is now made
non-virtual. Probably, it is not useful as a virtual base class.
Also modernize and simplify code, fix formatting, support
ID3v2FrameFactory, fix updating the internal chunk bookkeeping
after file modifications, stripping ID3 and DIIN tags.
Provides a unified API for complex properties in the same way as
the Properties API in the C bindings. Since constructing and
traversing complex properties in C is a bit complicated, there
are convenience functions for the most common use case of getting
or setting a single picture.
TAGLIB_COMPLEX_PROPERTY_PICTURE(props, data, size, "Written by TagLib",
"image/jpeg", "Front Cover");
taglib_complex_property_set(file, "PICTURE", props);
and
TagLib_Complex_Property_Attribute*** properties =
taglib_complex_property_get(file, "PICTURE");
TagLib_Complex_Property_Picture_Data picture;
taglib_picture_from_complex_property(properties, &picture);
Provides a dynamic interface for properties which cannot be represented
with simple strings, e.g. pictures. The keys of such properties can
be queried using `complexPropertyKeys()`, which could return for example
["PICTURE"]. The property can then be read using
`complexProperties("PICTURE")`, which will return a list of variant maps
containing the picture data and attributes. Adding a picture is as
easy as
t->setComplexProperties("PICTURE", {
{
{"data", data},
{"pictureType", "Front Cover"},
{"mimeType", "image/jpeg"}
}
});
