Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Recent Posts
1
Movie/Multichannel audio / Re: [REQ] Which codec for (S32_LE) multichannel lossless RECORDING ?
Last post by bryant -
Did you ever find a solution for this?
Hi there, I'm still experimenting with:
https://github.com/MarcoRavich/hALSAmrec/

Yeah, I know you're looking at that. You linked to it in your first post also, and I checked it out.

But your question was about the possibility of compression, and that's what I answered then, and was wondering about now.
3
CD Hardware/Software / Re: A newbie needs clarifications about TOC reports
Last post by CarloSadarusa -
Why 3 different values for the same CD?
You can use this tool to look up the musicbrainz disc id and freedb id from an EAC/XLD log. If it exists in those databases then you at least know the version/edition you have and should also be able to verify your rip. Obviously this isn't something you'll want to do with 100s of CDs as it'll be quite time consuming.

Some CDs can show "shifted" &/or "drift" TOCs.

Thanks for the help/clarification and the link.
I used directly this: http://db.cuetools.net/?tocid= by adding the tocid contained in the log to check.
That way I was sure that the CD is the same that I have.
From here I have discovered that the TOC is different from EAC to CT and MB.
Sometimes even the tracks duration time differers by a few between log and what is reported here.

Almost all my logs report 0 as Starting Sector while CTDB and MB reports 150 in every CD i checked.
An audio CD has a 2 second (150 sector) Lead-In followed by the program area. The Lead-In is where the TOC is stored. ref: https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio#Data_structure
The EAC extraction log TOC excludes the 150 sector Lead-In and starts at the beginning of the program area.
The CT and MB databases show from the beginning of the CD (which includes the 150 sector Lead-In).

Quote
Does it matters if AR reports no errors and high confidence?
The AccurateRip and CUETools databases only use the audio in the program area to calculate checksums used for verification.


Thanks for the clarification.
So I guess everything is fine since both says "Accurately Ripped" (with high number of confidence)
4
CD Hardware/Software / Re: A newbie needs clarifications about TOC reports
Last post by korth -
Almost all my logs report 0 as Starting Sector while CTDB and MB reports 150 in every CD i checked.
An audio CD has a 2 second (150 sector) Lead-In followed by the program area. The Lead-In is where the TOC is stored. ref: https://en.wikipedia.org/wiki/Compact_Disc_Digital_Audio#Data_structure
The EAC extraction log TOC excludes the 150 sector Lead-In and starts at the beginning of the program area.
The CT and MB databases show from the beginning of the CD (which includes the 150 sector Lead-In).

Quote
Does it matters if AR reports no errors and high confidence?
The AccurateRip and CUETools databases only use the audio in the program area to calculate checksums used for verification.
5
CD Hardware/Software / Re: A newbie needs clarifications about TOC reports
Last post by jaybeee -
Why 3 different values for the same CD?
You can use this tool to look up the musicbrainz disc id and freedb id from an EAC/XLD log. If it exists in those databases then you at least know the version/edition you have and should also be able to verify your rip. Obviously this isn't something you'll want to do with 100s of CDs as it'll be quite time consuming.

Some CDs can show "shifted" &/or "drift" TOCs.
7
CD Hardware/Software / A newbie needs clarifications about TOC reports
Last post by CarloSadarusa -
Hi, first post here.
I recently learned about EAC and started using it.
Ripped a bunch of CDs, obviously after configuring AR and the drive.
Everything went smooth until checking logs, the TOC section to be exactly.
According to AR the tracks were ripped accurately (with high confidence); even CTDB plugin reported high accuracy.
As I said earlier the problem lies with the TOC; it turns out that EAC, CTDB and MusicBrainz all reports different TOC value (especially Starting Sector).
Almost all my logs report 0 as Starting Sector while CTDB and MB reports 150 in every CD i checked.
For this reason almost all tracks have different crc between my rips and CTDB/MB due to different TOC positions.
My main questions are:
Why 3 different values for the same CD?
Who should I trust for accuracy?
Does it matters if AR reports no errors and high confidence?

Thanks
8
CD Hardware/Software / Re: AudioCD checking station for thrift shop
Last post by gunverth -
Does Swedish law allow user to get help ripping their CDs and selling the CD with an AccurateRip verified file?
(Though I can only imagine the malware vandalism if you allow them to plug stuff into your computer.)
That would be EU law. Not sure about that and it’s not my purpose anyway. This project is only for QC personell doing a quick check for data integrity of some valuable but scratched discs. I think I have found a ”recipe” with cdparanoia on debian that just reads, checks and logs: ’cdparanoia -qpXL 1- /dev/null’

AccuriteRip hasn’t been helpful for anyone I know. The pressings sold here very often doesnt match the database, so it’s more or less ”worthless”.
10
Support - (fb2k) / Re: BUG? External album art in subfolder not found/displayed if stored on huge hdd
Last post by Frenzel -
I did the testing with Process Monitor for fb2k v2.0 and for fb2k v2.1, thanks for your proposal. Obviously v2.1 does not even seem to attempt to access the artwork subfolder here in my example...

You may compare the different behavior of the two versions taking a look at the screenshots  I made from Process Monitor while loading the music files (of course from same storage directory).

Very strange... :-(