or Connect
Head-Fi.org › Forums › Equipment Forums › Portable Source Gear › The iBasso DX50 Thread - Latest firmware: 1.9.4 - January 24, 2016
New Posts  All Forums:Forum Nav:

The iBasso DX50 Thread - Latest firmware: 1.9.4 - January 24, 2016 - Page 577

post #8641 of 18427
Thread Starter 
Quote:
Originally Posted by Fluvance View Post
 

Just a quick question for anyone who knows the answer. Will the heat from leaving my DX50 in my pocket harm any components, like the capacitors? Thanks in advance.

Nop I carry my DX50 in my pocket every day while transiting and listen to music while there, it never failed that is because the inside is designed such that the space is more than ample. I know I opened it up. ;)

post #8642 of 18427
Thread Starter 
Quote:
Originally Posted by Cotnijoe View Post
 

unless ur body is a furnace... you should be fine.

:devil_face: lol

post #8643 of 18427
Thanks Soren for taking the reins and Music heaven for helping with the thread. I think it is more helpful and user friendly already. biggrin.gif
post #8644 of 18427
Thread Starter 

@Sorensiim when you have a minute can you please warn our DX50 users on the first page or FAQ about the following:

 

Under 1.2.6 now the scanning algorithm creates a new directory on the SD card called .audio_data and a database name audio.db. I do not know for certain what's in that database but my instinct tells me the scanning results (most likely cover arts info - who knows?). If you loose your cover arts, I would strongly advise you to delete the directory and re-scan your SD card library or else you won't have the cover arts showing on your DX50. Once it is done, then just keep it there for the dap to figure out what needs to be added. Thanks iBasso for introducing additional artifacts on the external SD card that creates more trouble than it is worth. :confused: I would suggest you add the playlist in there, that would be more useful.

 

One more thing, if you now look into your .album_img directory on your internal DX50 memory, it does not contain path names any longer just some sort of fixed coded strings which most likely works with the audio.db database referred above, so now we have two locations to worry about for scanning results.

 

 I am going to do an experiment and switch my SD card to see what happens to the other one, if it will be faster and keep the scanning results intact when switching. Nope no cigars here, scanning is done as if the card got inserted for the very first time.


Edited by musicheaven - 12/14/13 at 2:20pm
post #8645 of 18427
Quote:
Originally Posted by musicheaven View Post

Under 1.2.6 now the scanning algorithm creates a new directory on the SD card called .audio_data and a database name audio.db. I do not know for certain what's in that database but my instinct tells me the scanning results (most likely cover arts info - who knows?).
audio.db is a sqlite3 database containing: full path to each track, file name of each track, track title, artist, album, and what looks like a MD5 hash. These hashes appear to correspond to the album artwork file names in the .album_art directory on the internal store. It may or may not also contain album art bitmaps but the size of the file suggests that it does.
post #8646 of 18427
Holy ****, you guys are basically reverse engineering the DX50!
post #8647 of 18427
Thread Starter 
Quote:
Originally Posted by ratinox View Post


audio.db is a sqlite3 database containing: full path to each track, file name of each track, track title, artist, album, and what looks like a MD5 hash. These hashes appear to correspond to the album artwork file names in the .album_art directory on the internal store. It may or may not also contain album art bitmaps but the size of the file suggests that it does.

Thanks, I was gonna say GUID but that is in the MS world, MD5 hash would make more sense here, it is a coding reference to this db file, reminds me of Apple and their own scheme.

 

I am glad about one thing now, I can safely resume my tag versus cover art study I was doing before the cover arts all of a sudden disappeared. :deadhorse:


Edited by musicheaven - 12/14/13 at 2:29pm
post #8648 of 18427
Thread Starter 
Quote:
Originally Posted by Sorensiim View Post

Holy ****, you guys are basically reverse engineering the DX50!

That's what happens when you keep switching firmware and find out things don't work quite the same so you get curious and start digging around until things re-appear and becomes clearer. :wink_face:

post #8649 of 18427
Quote:
Originally Posted by Sorensiim View Post

Holy ****, you guys are basically reverse engineering the DX50!
Figuring out how things work -- or don't work when they should -- is part of what I do for a living. smily_headphones1.gif
post #8650 of 18427

sometimes people on this forum make me feel so unintelligent :ph34r:

post #8651 of 18427
Thread Starter 
Quote:
Originally Posted by ratinox View Post


audio.db is a sqlite3 database containing: full path to each track, file name of each track, track title, artist, album, and what looks like a MD5 hash. These hashes appear to correspond to the album artwork file names in the .album_art directory on the internal store. It may or may not also contain album art bitmaps but the size of the file suggests that it does.

Sorry about that I noticed you already knew the database source so here is what I further found: I opened up the audio.db file, obviously a binary file and it is SQLite, a public domain library so for the courageous SQL mobile developer that could be fun to tap.

 

>>> http://www.sqlite.org/

SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. SQLite is the most widely deployed SQL database engine in the world. The source code for SQLite is in the public domain.

<<<

 

So here we go, thanks iBasso for using SQLite pretty cheap like free. :biggrin:

 

Well like you said the coded MSD strings are right there with the physical external card reference, now we only need a SQLite app that reads the internal memory and external card and we got ourselves a home made scanner. lol

 

Now we need to know how the playlist works.


Edited by musicheaven - 12/14/13 at 3:48pm
post #8652 of 18427
Quote:
Originally Posted by musicheaven View Post

So here we go, thanks iBasso for using SQLite pretty cheap like free. biggrin.gif

Well like you said the coded MSD strings are right there with the physical external card reference, now we only need a SQLite app that reads the internal memory and external card and we got ourselves a home made scanner. lol

Now we need to know how the playlist works.

When you need more than a simple key-value store but less than a full blown database server then SQLite is probably the go-to system. Pretty much every Linux distribution out there, of which Android is a collection of supersets, has and uses SQLite. Macintosh uses it extensively, too. Firefox and Thunderbird? Bookmarks and cookies, among several other things, are stored in SQLite databases. Same with Google Chrome. It's damned near ubiquitous.

Figuring out the schema for their database is something that I'll leave to those who like mucking about with databases (I, for one, do not).

The playlist system should be simple. With any luck they'll be bog-standard m3u8 files. Moving them from /data to accessible storage would then be a simple process and I'm a little surprised that iBasso hasn't done that, yet.
post #8653 of 18427
Thread Starter 
Quote:
Originally Posted by ratinox View Post


When you need more than a simple key-value store but less than a full blown database server then SQLite is probably the go-to system. Pretty much every Linux distribution out there, of which Android is a collection of supersets, has and uses SQLite. Macintosh uses it extensively, too. Firefox and Thunderbird? Bookmarks and cookies, among several other things, are stored in SQLite databases. Same with Google Chrome. It's damned near ubiquitous.

Figuring out the schema for their database is something that I'll leave to those who like mucking about with databases (I, for one, do not).

The playlist system should be simple. With any luck they'll be bog-standard m3u8 files. Moving them from /data to accessible storage would then be a simple process and I'm a little surprised that iBasso hasn't done that, yet.

 Yes, I noticed the list of companies using the database are well known corporations. I quickly checked the tables available in audio.db and we have 3 of them, the main one is the MUSIC table, how original ;) Well they have all the tools to access them but really that is quite a bit of work just to peak at it so best is to leave it alone even if one would create a windows and/or Mac apps that would perform the scanning, it will all be for nothing because it scans the card anyway as soon as you pop it in. It was a good exercise and to know that now we need to care about this database on the external card so the whole cover media and music library will work.

 

We need to ask them to do something about the playlist though, the firmware burning is really taking its toll. It becomes onerous to have to enter the playlist each and every time the card is removed and inserted or the firmware is burned in. I think their sd card database can be somewhat more intelligent and allow playlists to be saved.


Edited by musicheaven - 12/14/13 at 4:12pm
post #8654 of 18427

Regarding the gapless discussions, etc - I am 100% with jj69 on this in that the music should play exactly as the original audio CD intended - no more, no less, not complicated.  Now it could be that in conversion to other formats this exact behavior somehow can be altered - I am no expert on that.  I am happy with how 1.2.5 deals with the concept and based on all that has been said about 1.2.6 have not upgraded to that yet.

 

I have suggested in the Bug List, Wish List Fix thread (and sent to iBasso) it would be nice to have the option to play a single track and stop in addition to what we have already.  Would also like to see the EQ actually be +-6 db like it appears instead of 0 to -12db.  Not a huge deal though.

 

Cheers for now,

Tim

post #8655 of 18427
Thread Starter 
Quote:
Originally Posted by CobraMan View Post
 

Regarding the gapless discussions, etc - I am 100% with jj69 on this in that the music should play exactly as the original audio CD intended - no more, no less, not complicated.  Now it could be that in conversion to other formats this exact behavior somehow can be altered - I am no expert on that.  I am happy with how 1.2.5 deals with the concept and based on all that has been said about 1.2.6 have not upgraded to that yet.

 

I have suggested in the Bug List, Wish List Fix thread (and sent to iBasso) it would be nice to have the option to play a single track and stop in addition to what we have already.  Would also like to see the EQ actually be +-6 db like it appears instead of 0 to -12db.  Not a huge deal though.

 

Cheers for now,

Tim

Makes sense if you still buy CDs which now is the least medium being purchased, now with music download, this does not apply any longer. I prefer the Apple gapless function, play the first song, stitch the second and play it immediately. It's simple, not complicated and more with our time.


As far as the EQ, I truly don't care - I just don't use it I like the music untouched as was recorded and the response as flat as possible to let the music come to life.

 

As I shown, 1.2.5 gapless still did not fully work which is still surprising to me that most DX50 owners thought it did. Version 1.2.6 does not suffer from  a one second delay at the end of the first song when the second song starts so this is more gapless than the prior release. The only annoying thing is to force crossfade without asking for it, if it was optional then everything would be fine.


Edited by musicheaven - 12/14/13 at 5:05pm
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Portable Source Gear
Head-Fi.org › Forums › Equipment Forums › Portable Source Gear › The iBasso DX50 Thread - Latest firmware: 1.9.4 - January 24, 2016