1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.

    Dismiss Notice

Astell&Kern AK380

Discussion in 'Portable Source Gear' started by Dopaminer, Apr 22, 2015.
526 527 528 529 530 531 532 533 534 535
537 538 539 540 541 542 543 544 545 546
  1. TaylorDawe
    Quite frankly, Monty, I find that none of that is a problem using Windows XP, (although this old system can't read cards over around 30gig or less), never mind a newer OS. The only time I had similar issues was way back when I first got my 380 and used the 'internal' file operations on the player. This simply didn't work and would corrupt files, lose music and at times make an SD Card unreadable (by the player). So I reverted to hooking the player up to the PC and using my file software. I have never had a problem using a windows computer. However, I find it hard to believe that AK iRiver would make a product that can't be easily managed by the millions of apple users in the world. My sympathy for the problems you are experiencing (and I feel guilty, now, for extolling the virtues of the ripper to you before you got it).
  2. bflat
    Not necessarily. The Android OS need to scan for media files is completely internal to Android and PC operating system has nothing to do with it. However, AFT displaying an "empty" SD card even though there are files on it is definitely an AFT problem. It's really bad on Android based DAPs with 2 SD card slots. I had an Onkyo DP-X1 and whenever I turned it on, I literally would have to wait 10-15 min before AFT would display all the folders.
    Just to make sure frustrations are aimed at the right party - Android supports both MTP and UMS. The later is what flash drives use and both Windows and Mac OS work equally. However, the problem with UMS and Android is that UMS requires Android to unmount the SD card in order for your PC to access it. That means the Android system cannot access the SD card while your PC is connected to it. It would be ok if Android didn't allow apps to get moved to the SD card back with Honeycomb release. Since bad things happen when apps "vanish" from Android, Google decided to make MTP the default protocol with Honeycomb and later versions. MTP does not require the SD card to be unmounted and it can simultaneously connect to both Android system and external PC. This is why you can play music on your AK DAP while copying files to your SD card. The other reason why Google changed to MTP is that it obscures system files on Android so users don't accidentally delete system files. However, MTP was a Windows only protocol until it became a universal spec around 2008. This is also about the time when Google realized Mac OS doesn't natively support MTP so they created the AFT utility. The Linux community developed several MTP utilities via open source.
    Depending on your perspective, you can say Apple is to blame in that they don't support MTP natively in their OS. Or you can blame Google for not updating their AFT with better features. I think the last version is still dated 2012. Or you can blame AK for not having file transfer over wifi with the AK Connect app.
    IMHO, Apple is not going to invest in supporting another data xfer protocol that requires a wired connection. Everything Apple does points to wireless for the foreseeable future. Look at iTunes, once you enable Apple Music, every album you rip, magically shows up on your iPhone without any need for a wired connection to your Mac. I just wish it can support lossless. However, the workflow is brain dead easy.
  3. rbalcom

    Windows just seems to handle Android based devices smoother than OS X does, but problems can still ocurr during file transfers.  The Library on the AK380 points to the track location like a file path. When you move the files from the Ripping Folder to the sdcard, The AK380 has to do a media scan to find the moved files and update the file path. It does this each time it is turned on, but when there are a lot of changes it can take a long time to complete. Manually initializing the scan does away with the looking for changes or additions part and just starts over with a new scan to replace the old information rather than updating each entry.
    The AK380 tells you that "SD Card safely removed", but it actually means that the sdcard is mounted. It takes a little time after power up for the card to mount and give you that notification in the Notification Bar. You should also be able to view what is on the card using the Folder view.
  4. Uncle Monty
    Thanks for the advice everyone - this issue is a bit complicated. Hopefully, once I get the music back on the SD card I can just forget about it.
    Once the music has transferred from the EHD to the SD Card - should I do a manual media scan so the player can work out where everything is? When I two copies of everything on the player last night (before today's disaster) it could play the same files easily back and forth from internal memory and SD card and on shuffle it chose from both memories completely at random, so was working fine. Went from hero to zero overnight...
  5. rbalcom
    I would initialize the media scan. To me, it would be more efficient than letting it sort it out on its own.
  6. Uncle Monty
    As an aside, a previous poster had pointed out that the FLAC files produced by the Ripper were larger than 'normal' FLAC files and it seems to be true - despite what I previously thought, the internal memory was filled with around 5,000 FLAC files, giving a total volume (256Gb + 256Gb) of approx 10,000 songs, whereas my modded 500Gb iPod holds approx 16,000 ALAC music files. I always thought ALAC and FLAC files were about the same size, so it seems The Ripper does create inordinately large files....
  7. ThomasHK
    There are different quality setting for FLAC that all result in Lossless compression but are more/less CPU intensive to encode. Hence different file sizes. 
  8. Uncle Monty
    Does this mean the larger FLAC files produced by the Ripper should sound better? I compared some of these files with smaller ALAC files from my iTunes and I couldn't really hear a difference, though that could have been down to the quality of the recordings and my battered ears.
    Everything working again now btw - thanks for all help and advice. Apparently there is a way to transfer files from internal memory to SD card on the player itself without plugging it in to any computer and / or using Android File Transfer - has anyone tried this?
  9. b0ssMax
    Anyone using the ak380+ripper to rip cds using wav? How is the cover art done? Is it embedded or a separate file produced?
  10. Uncle Monty
    The cover art etc comes from Gracenote, so as long as you've got a good wifi signal you'll get most - though not all - of the artwork. I noticed that my iTunes gets more cover art than Gracenote seems to.
  11. ThomasHK
    No. Flac is lossless. 
  12. Uncle Monty
    Why do people use WAV?
  13. haiku

    Some claim it sounds best, because the DAC does not have to decompress the file to play it. Decompressing a file (like FLAC, ALAC etc.) puts too much workload on the DAC, so they say. So far the theory. To me, FLAC sounds best.
  14. bmichels
    honestly, I can't hear the difference....   Am I the only one ? 
  15. b0ssMax

    I have a player that can only read wav and mp3, so after decoding some flacs to wav, it got me thinking ok comparing wav vs flac (compression 7) to see if ak380 will not get as hot with wav as compared to flac and whether there's a significant improvement in sq.

    I've heard some folks talk about wav saying it's better (sq) so I'm thinking of trying it out myself.

    I did the flac vs mp3 and mp3 192vs320 years ago. Later on i realized my source was the problem.
526 527 528 529 530 531 532 533 534 535
537 538 539 540 541 542 543 544 545 546

Share This Page