Having already tested this thoroughly with 1.2.3beta and 1.2.5, I can assure everyone that the most efficient for scan purposes is to have NO embedded artwork but each album folder should have the artwork in a file named folder.jpg (in the same folder as the music files) Highly recommend 300x300 size and a max of 500x500 if only for compatibility with many other DAPs as well.

Using this protocol, I have minimised the time it takes to scan a full 64gb MicroSD card.

Nice, test for testing. Do you know if png files are supported too (i.e. folder.png)?

Nice, test for testing. Do you know if png files are supported too (i.e. folder.png)?

I've not tried png files and probably not inclined to in the interest of maximum compatibility. If the images you've embedded are png files you can use Mp3tag.exe to extract them and save them to the folder as a JPEG named folder.jpg in a very simple process either in your source or directly on the SD card. I extracted the album art then did a batch removal of the embedded images. Great program Mp3tag.

I've not tried png files and probably not inclined to in the interest of maximum compatibility. If the images you've embedded are png files you can use Mp3tag.exe to extract them and save them to the folder as a JPEG named folder.jpg in a very simple process either in your source or directly on the SD card. I extracted the album art then did a batch removal of the embedded images. Great program Mp3tag.

Yeap, I've been using mp3tag for years too. I don't think there's another program that's as easy to use and useful as it I'll try extracting it as a jpg then, thanks

Having already tested this thoroughly with 1.2.3beta and 1.2.5, I can assure everyone that the most efficient for scan purposes is to have NO embedded artwork but each album folder should have the artwork in a file named folder.jpg (in the same folder as the music files) Highly recommend 300x300 size and a max of 500x500 if only for compatibility with many other DAPs as well.

Using this protocol, I have minimised the time it takes to scan a full 64gb MicroSD card.

I have tested it too and yes the album artwork with the folder.jpg works but if you don't embed the artwork in the file, the song list will not display the artwork for each individual file so that's the compromise for not embedding it.

I have tested it too and yes the album artwork with the folder.jpg works but if you don't embed the artwork in the file, the song list will not display the artwork for each individual file so that's the compromise for not embedding it.

Which screen are you referring to as "Songlist"?

I've only ever seen the album art in the album list and on the play screen... Embedded or not...

Edit: To clarify, any title list that I recall seeing always displayed an icon showing the file type beside the title....Edited by Jpfe8851 - 11/24/13 at 4:01am

I've only ever seen the album art in the album list and on the play screen... Embedded or not...

Edit: To clarify, any title list that I recall seeing always displayed an icon showing the file type beside the title....

This is my setup:

Artist\Album
Song 1
Song 2
...

The folder.jpg is saved in the album folder.

When I browse the album list, the artworks found in the album folder show. But when browsing the song list after I selected the album (unless I embed the artwork in the song file), it does not display any artwork except the standard iBasso icons for the file type (mp3, Flac, etc...).Edited by musicheaven - 11/24/13 at 4:15am

That is curious.... Are you able to show us an image of the Songlist with the artworK? Even when I had embedded artwork, I only ever saw the file type icon. The album art only shows up in the album list.

For the heck of it, I just grabbed a spare SD card, put a couple albums on it using your structure which by the way is also my default structure and re-embedded the artwork and the song list still shows the file type icon... Artwork only appears in the album list, just as when the file contains no embedded artwork but the folder.jpg exists in the same folder as the tracks. As I said earlier, I've never seen artwork in the Songlist.

For the heck of it, I just grabbed a spare SD card, put a couple albums on it using your structure which by the way is also my default structure and re-embedded the artwork and the song list still shows the file type icon... Artwork only appears in the album list, just as when the file contains no embedded artwork but the folder.jpg exists in the same folder as the tracks. As I said earlier, I've never seen artwork in the Songlist.

I did the same thing, it just bugged me and I had to get the exact behavior, so here is my setup:

I have 1 artist folder with the following setup:

Delerium\Poem (embedded artwork and folder.jpg) <- MP3 (I also used a different image so I know exactly where it would go)

Delerium\Nuages Du Monde (embedded artwork but no folder.jpg) <- MP3

Delerimum\Chimera (no embedded artwork folder.jpg) <- MP3

Delerium\Karma (no embedded artwork and no folder.jpg) <- MP3

Results I got:

It only uses the folder.jpg for both album and my music page. So you are right, from now on I won't bother embedding the artwork into the music file. There is no artwork displayed in the song list after the album is selected.

These are the two BASH scripts that I use to work around the lack of editable playlists and lack of ReplayGain support. The plhack file scans through a m3u playlist file, sets each file's artist tag to the playlist's name, and sets each track number sequentially (so the 2196th file will have track number 2196). The undo script generated by plhack restores album and track tags because it's faster than copying files out of my library. The big drawback is that a file can be in only one playlist with this hack but it's better than nothing for my needs.

Lines 31-33 contain the volume transcoding. Line 31 retrieves the album gain from the tag, line 32 transcodes using ffmpeg's volume filter (-af volume), and line 33 removes any RG tags from the transcoded file because they're no longer accurate. No real drawbacks to this hack other than being a destructive transformation (I'm not sure if the volume filter is reversible for FLAC to FLAC transcoding). Bonus: ImageMagick (convert) used to scale the album art files down to 100x100 pixels.

My back/fwd buttons are extremely unresponsive. They will work only once in a while, and when they work it is usually with a much higher delay than the touch-screen buttons. It doesn't seem like a hardware issue to me. Anyone else?

It's mostly a hardware issue. Mango is running on a single core, single thread CPU and it puts pretty much all of its effort into expanding music files and feeding the DAC. There's a bit of latency as it shifts to handling user input. The touch screen seems more responsive because that latency happens while you wait for the screen to activate.