[jkauff]

  Perfect.  Thanks so much for the info.  After doing more research, that's exactly what I ordered.  What do you use to handle customized playlists, or do you just load the card with albums and then switch them out manually?  Part of the issue I've run into is that, beyond using Dapper, which is a great app by the way, it's been laborious to keep track of all the music I want to load and swap out, even on a 64GB card.  I can't imagine what that would be like on a card double that size.

I do everything manually, and I don't use playlists. I use Shuffle mode quite a bit, so I don't fill up the card, I just delete albums I'm tired of and copy a new bunch over. I've found Shuffle doesn't work very well with too many albums.

 

[fburgos01]

 Totally agree with you on all points; the sound is stellar for those of us who are particular about how we listen to our music.
 
Speaking of 128GB cards, I'm upgrading from my 64GB Transcend and was looking for some suggestions on which to purchase.  Reading random reviews can be a bit daunting and they usually don't apply to DAP read/write speeds (I sync from my library with Dapper.)  Any suggestions?

I've used SanDisk Ultra cards almost exclusively. Never had a problem with any of them, including the 128GB card. Read speeds have never been an issue. I don't write directly to the X3, I use a USB 3.0 MicroSD adapter plugged into my computer when I'm loading up the card, and the speeds are about as high as you can expect for MicroSD.

I'm using sandisk 200gb

Sent from my ONE A2005 using Tapatalk

 

[AlphaGeek1]

I am getting an X3 1st gen FiiO.  I chose this unit because I can afford it and because I don't like big circles so the HMI is much more to my liking.
 
As for the firmware.. if it truly EOL, then why not just open source it so others can continue?  It's not like the hardware is non-viable like an 8-track player or something.  What do they have to lose?  They're a HARDWARE company, so I can't understand how they wold benefit from keeping the software under lock and key.  Can someone explain to me how that might be to their advantage?  (unless of course it's already been opened and I still have more reading to do!)

 

[ClieOS]

  I am getting an X3 1st gen FiiO.  I chose this unit because I can afford it and because I don't like big circles so the HMI is much more to my liking.
 
As for the firmware.. if it truly EOL, then why not just open source it so others can continue?  It's not like the hardware is non-viable like an 8-track player or something.  What do they have to lose?  They're a HARDWARE company, so I can't understand how they wold benefit from keeping the software under lock and key.  Can someone explain to me how that might be to their advantage?  (unless of course it's already been opened and I still have more reading to do!)

 
We have been through this a long long time ago - there is a contract between FiiO and the SoC supplier that will not allow FiiO to open source the firmware. In case you don't know, SoC is basically the CPU of the player. All the basic source code that required to run the player comes from the SoC supplier as part of the package deal when buying the SoC, then FiiO makes changes and improvement on top of it to compile the firmware. Thus without the SoC supplier's consent, there is nothing FiiO can do about it - and as far as SoC supplier is concerned, the source code is their trade secret. While X3 might have been out of production, the SoC is still very much being used on many (if not most) of the DAP in the market right now. They are not going to open source their trade secret just so their competitor can have any chance to gain benefit of it. When you are asking FiiO to open source the firmware, you are barking up the wrong tree.

 

[Drakonas]

  I've deleted the cue sheet files to get rid of the gaps (no big deal, I listen mostly to whole albums), which means I have an album long "tracks", which means I have to use track position memory.

I am curious if you ever solved your problem. From what I know of Cue sheets, the gaps' lengths are defined inside the cue sheet and if not set up correctly when the CD is ripped, they will produce gaps between tracks. To properly create a CUE file with EAC at rip time, most people don't realize you're supposed to use EAC's "Detect Gaps" feature BEFORE creating the Cue sheet. Also you should always choose the "Multiple WAV files with gaps (Noncompliant)" option when creating a cue file after you used the "Detect Gaps" feature, so it appends any existing gaps to the end of the previous track. This creates a 1 to 1 CUE file index of the original CD.
 
Even though it's been half a year, I wanted to put my two cents in and provide some insight on this that I hope might help. If, however, that was not your issue I am sorry.

 

[HWTest]

Thank you for your interest.
 
No, sadly I didn't.
 
I rip to a single file with a cue sheet.
I don't think there is anything wrong with my rips.
They play without a problem on a PC (Foobar) and on my Rockboxed iRiver H-140 and H-10.
When I verify the rips in CUETools, they are accurate.
When burn the rip to a CD and rip it again (I've set the read/write offset correctly), they are identical - bit perfect copies.
I've tried manipulating the cue sheets - it didn't help.
If there is no index 0, only indexes 1, then there is no gap, but FiiO inserts gaps.
I could try to split the rips to individual tracks but I don't see, how it could help, because FiiO has it's problems with gapless playback of individual files.