Review Request: Some changes to the handling of cover art reading and writing

[Bart Cerneels]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104513/#review12297
-----------------------------------------------------------


Overall I think this is a lot of config for a pretty esoteric feature. It's nice to have embedded covers, but can't we implement a default that works for the 98%?


Screenshot: 
<http://git.reviewboard.kde.org//r/104513/#scomment45>
    Append is a bit technical, would use "Add new cover".


Screenshot: 
<http://git.reviewboard.kde.org//r/104513/#scomment46>
    A combo-box is not ideal for <4 items to choose from. I would personally prefer a checkbox group.
    But as you can see lower in the dialog for transcoding, it does save space in an already overcrowded page.


shared/tag_helpers/ASFTagHelper.cpp
<http://git.reviewboard.kde.org/r/104513/#comment9664>

    You should probably use a static const or #define here. It's self-documenting if the name is good.
    Alternatively you can add a line of comment explaining where the 1024 comes from.



shared/tag_helpers/ID3v2TagHelper.cpp
<http://git.reviewboard.kde.org/r/104513/#comment9666>

    Is there any caching of this cover higher up in the stack?



src/dialogs/CollectionSetup.h
<http://git.reviewboard.kde.org/r/104513/#comment9667>

    You are using the same hardcoded value multiple times. Better use something cleaner where you define the strings only once.


- Bart Cerneels


On April 8, 2012, 5:54 p.m., Daniel Faust wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104513/
> -----------------------------------------------------------
> 
> (Updated April 8, 2012, 5:54 p.m.)
> 
> 
> Review request for Amarok.
> 
> 
> Description
> -------
> 
> This patch includes a list of small changes that are supposed to give the user more control over the cover writing process and unify it for all file formats.
> 
> 1. The user can set the maximum cover size in the config dialog instead of having a fixed 200px. (BR 279493)
> 2. The user can set how existing covers should be handled:
>    - 'Replace existing front covers' (almost the current behavior except for m4a files and some cases where more than one 'front' cover exists)
>    - 'Replace all existing covers'
>    - 'Append new cover' (actually it's a prepend, doesn't work with wma files, though; the current behavior for m4a files)
> 3. Unify the reading of covers. Instead of searching for the biggest cover like it was implemented for some file formats from now on the first 'front' cover will be taken. If there is no 'front' cover, the first 'other' cover will be taken (if present). The 1kb limit is still present.
> 4. Fix a potential bug where covers couldn't be found in mp3 files if the first cover was neither a 'front' cover nor 'other' or smaller than 1kb.
> 
> 
> This addresses bug 279493.
>     https://bugs.kde.org/show_bug.cgi?id=279493
> 
> 
> Diffs
> -----
> 
>   shared/tag_helpers/ASFTagHelper.cpp 93e6031 
>   shared/tag_helpers/ID3v2TagHelper.cpp 27e0cf0 
>   shared/tag_helpers/MP4TagHelper.cpp faeae0a 
>   shared/tag_helpers/VorbisCommentTagHelper.cpp 1fbb437 
>   src/amarokconfig.kcfg 5610c4a 
>   src/core-impl/collections/db/sql/SqlMeta.cpp e663adf 
>   src/dialogs/CollectionSetup.h 3146f17 
>   src/dialogs/CollectionSetup.cpp f1b7850 
> 
> Diff: http://git.reviewboard.kde.org/r/104513/diff/
> 
> 
> Testing
> -------
> 
> I have tested writing covers with flac, mp3, and wma files.
> 
> 
> Screenshots
> -----------
> 
> 
>   http://git.reviewboard.kde.org/r/104513/s/508/
> 
> 
> Thanks,
> 
> Daniel Faust
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20120410/212a187b/attachment.html>