Page 11 of 18

Re: SDTrans 384?

Posted: Fri Feb 19, 2016 4:48 pm
by randytsuch
rickmcinnis wrote:Meant to say something about those expensive cards in my post.

WHAT IS THE POINT?

I am using standard issue cards - SANDISK - they seem to work just fine.

What could possibly be the advantage of using such a card?

Only REDBOOK files for me - maybe if one was using the DSD facility and I say that only because I have no idea what that requires.

Maybe these allow LOTS of re-writes which will not matter to me since I am writing to them, once, and then leaving them alone?
explanation here:
http://www.tomsitpro.com/articles/flash ... 744-2.html

SLC flash is a more reliable, and expensive type of flash, versus MLC

I've seen people claim it sounds better, I have some SLC CF cards but never compared them "sound wise" to MLC cards.

And I knew getting you to do the comparison was a long shot, but I had to ask :)

I'll probably break down and spend the money.

But I still think my latest PC efforts are going to be worthwhile. I've seen posts lately about improvements by ripping in core mode. Most of my rips are flac only, and were done on a laptop. It will be a pain, but at some point I'll probably rerip my collection (or at least the cd's I listen to the most).

Randy

Re: SDTrans 384?

Posted: Fri Feb 19, 2016 7:27 pm
by nige2000
i have a slc sata-dom here i was supposed to test
not sure where it is now

i think i remember seeing slc sd cards on ebay in hk at almost reasonable cost

Re: SDTrans 384?

Posted: Fri Feb 19, 2016 7:51 pm
by frd1996
Let me add my 2c here.

The difference between SLC MLC and TLC is the endurance. By endurance I mean: how many write cycles the FLASH cell will handle before it's destroyed. More layers in FLASH cell means less write cycles are required. Size of the cells also matters - smaller cells, the quicker the they will wear off. Enterprise FLASH is simply simply last for more write cycles. The numbers are: around 100k write cycles for SLC, 3k for MLC and 1.5k for TLC.

The typical file system for SD card is FAT32. This file system is not great for the cards. At the begging of the file system there is a File Allocation Table and this table gets updated whenever you perform any write operation: writing file, renaming file, changing file attributes, etc... That means the FLASH cells holding FAT will be updated a lot and is the first candidate to fail.

If we consider how SD Card is used in a device such as SDTrans, we can clearly see that we the card will be read most of the time (unless SDTrans is doing something funky). The user would typically write the music on the card once and keep it there. Updates would happen on very rare occasions. And the SD cards are rather cheap, you can have many of them in use and you would rather swap them instead of updating their contents.

I agree with Rick on SLC cards - they are probably not worth investing, considering how they are going to be used.

As for "high quality" cards from ebay, I would stay away from them. I had few of them and they did not last even single write cycle. Now I am using Kingston cards. So far they have not failed me.

F

Re: SDTrans 384?

Posted: Fri Feb 19, 2016 9:31 pm
by rickmcinnis
Thanks FW for your considered opinion!

I doubt the SDTrans is doing any writes to the cards.

Hope ALL is well for you.

Take care,

Re: SDTrans 384?

Posted: Fri Feb 19, 2016 9:35 pm
by randytsuch
frd1996 wrote:Let me add my 2c here.

The difference between SLC MLC and TLC is the endurance. By endurance I mean: how many write cycles the FLASH cell will handle before it's destroyed. More layers in FLASH cell means less write cycles are required. Size of the cells also matters - smaller cells, the quicker the they will wear off. Enterprise FLASH is simply simply last for more write cycles. The numbers are: around 100k write cycles for SLC, 3k for MLC and 1.5k for TLC.

The typical file system for SD card is FAT32. This file system is not great for the cards. At the begging of the file system there is a File Allocation Table and this table gets updated whenever you perform any write operation: writing file, renaming file, changing file attributes, etc... That means the FLASH cells holding FAT will be updated a lot and is the first candidate to fail.

If we consider how SD Card is used in a device such as SDTrans, we can clearly see that we the card will be read most of the time (unless SDTrans is doing something funky). The user would typically write the music on the card once and keep it there. Updates would happen on very rare occasions. And the SD cards are rather cheap, you can have many of them in use and you would rather swap them instead of updating their contents.

I agree with Rick on SLC cards - they are probably not worth investing, considering how they are going to be used.

As for "high quality" cards from ebay, I would stay away from them. I had few of them and they did not last even single write cycle. Now I am using Kingston cards. So far they have not failed me.

F
At a high level, what you say is true. But the endurance you point to is really an artifact of how they work.
Did you look at my link?
It explains the difference in a little more detail.
IMHO, for reading, with a MLC, there is a greater change of read errors. Not sure how often this really happens, but a SLC has more margin for error than a MLC.
And I have no idea if this makes any difference in sound or not.

Randy

Re: SDTrans 384?

Posted: Fri Feb 19, 2016 9:43 pm
by rickmcinnis
Randy,

Concerning rips:

A fellow at Audio Asylum was experimenting with making a better ripping computer. I think he found that what he did did not make much difference.

I have been making as many rips as I can with my UBUNTU machine with the hope that the OS was less busy than WINDOWS. Unfortunately the good LINUX ripper can only rip recordings in some obscure database (it does use ACCURATE RIP) that was frustrating and limited. Very little orchestral and almost no oddball rock and roll.

I use dBPOWERAMP when I use WINDOWS, so that is my reference.

I am thinking about using the battery supply for the Music SDD - who knows if it would make a difference. The really BIG problem, I think, is the computer being connected to the internet. Now that I have got used to having the titles applied to the rips it would be hard to get unused to it. One part of me is considering trying one of my minimized WINDOWS installs for ripping but there again these machines can be connected to the internet but I have dismantled the internet capabilities so I am back to doing all of that typing for an unknown and likely marginal improvement (it does sound like I am slipping ...)

One thing for sure, one could not go wrong with slowing the machine down to as slow as it will run. One wonders if good cables could make a difference?

I look forward to hearing what you find.

Re: SDTrans 384?

Posted: Fri Feb 19, 2016 11:03 pm
by frd1996
randytsuch wrote: At a high level, what you say is true. But the endurance you point to is really an artifact of how they work.
Did you look at my link?
It explains the difference in a little more detail.
IMHO, for reading, with a MLC, there is a greater change of read errors. Not sure how often this really happens, but a SLC has more margin for error than a MLC.
And I have no idea if this makes any difference in sound or not.

Randy
Yes, I did read your link. Good information. Don't you think that read errors may be a consequence of write errors that happened in the first place? After all the read operation does not change the charge of the floating gate of the flash cell. Just speculating here - I am not a flash memory expert.

Also I wanted to point out one more thing. If we assume there are read errors (does not matter how), then we would not know about them while reading the file. The file FAT32 filesystem that is used does not have any checksum on datablocks.

F

PS. Sorry for off-topic

Re: SDTrans 384?

Posted: Sat Feb 20, 2016 1:27 am
by sima66
rickmcinnis wrote:Randy,

Concerning rips:

A fellow at Audio Asylum was experimenting with making a better ripping computer. I think he found that what he did did not make much difference.

I have been making as many rips as I can with my UBUNTU machine with the hope that the OS was less busy than WINDOWS. Unfortunately the good LINUX ripper can only rip recordings in some obscure database (it does use ACCURATE RIP) that was frustrating and limited. Very little orchestral and almost no oddball rock and roll.

I use dBPOWERAMP when I use WINDOWS, so that is my reference.

I am thinking about using the battery supply for the Music SDD - who knows if it would make a difference. The really BIG problem, I think, is the computer being connected to the internet. Now that I have got used to having the titles applied to the rips it would be hard to get unused to it. One part of me is considering trying one of my minimized WINDOWS installs for ripping but there again these machines can be connected to the internet but I have dismantled the internet capabilities so I am back to doing all of that typing for an unknown and likely marginal improvement (it does sound like I am slipping ...)

One thing for sure, one could not go wrong with slowing the machine down to as slow as it will run. One wonders if good cables could make a difference?

I look forward to hearing what you find.
From my experience everything that affects play, the same way affect ripping!
I take ripping even more seriously, because there is no improving of the ripped file after ripping is done. So if you missed some details, or ad more noise in the ripping process, the better your player gets, the more will reveal those mistakes!

And yes, I typed! :)

Re: SDTrans 384?

Posted: Sat Feb 20, 2016 1:31 am
by nige2000
actually think it was slc cf cards i seen on ebay not sd my mistake
although i think our systems would be extremely advanced if the next big thing was down to the difference of slc vs mlc

think ppa stated slc was better dont know of other sq reports?

Re: SDTrans 384?

Posted: Sat Feb 20, 2016 1:36 am
by nige2000
sima66 wrote:
rickmcinnis wrote:Randy,

Concerning rips:

A fellow at Audio Asylum was experimenting with making a better ripping computer. I think he found that what he did did not make much difference.

I have been making as many rips as I can with my UBUNTU machine with the hope that the OS was less busy than WINDOWS. Unfortunately the good LINUX ripper can only rip recordings in some obscure database (it does use ACCURATE RIP) that was frustrating and limited. Very little orchestral and almost no oddball rock and roll.

I use dBPOWERAMP when I use WINDOWS, so that is my reference.

I am thinking about using the battery supply for the Music SDD - who knows if it would make a difference. The really BIG problem, I think, is the computer being connected to the internet. Now that I have got used to having the titles applied to the rips it would be hard to get unused to it. One part of me is considering trying one of my minimized WINDOWS installs for ripping but there again these machines can be connected to the internet but I have dismantled the internet capabilities so I am back to doing all of that typing for an unknown and likely marginal improvement (it does sound like I am slipping ...)

One thing for sure, one could not go wrong with slowing the machine down to as slow as it will run. One wonders if good cables could make a difference?

I look forward to hearing what you find.
From my experience everything that affects play, the same way affect ripping!
I take ripping even more seriously, because there is no improving of the ripped file after ripping is done. So if you missed some details, or ad more noise in the ripping process, the better your player gets, the more will reveal those mistakes!

And yes, I typed! :)
think youll be a long time convincing people on the ripping thing
i cant imagine theres very many with a system resolving enough to prove it
id very much doubt it is measureable either