Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reconsider track_offsets[0], track_lengths[0] etc. #24

Closed
JonnyJD opened this issue Apr 20, 2013 · 2 comments
Closed

reconsider track_offsets[0], track_lengths[0] etc. #24

JonnyJD opened this issue Apr 20, 2013 · 2 comments
Assignees
Labels
Milestone

Comments

@JonnyJD
Copy link
Owner

JonnyJD commented Apr 20, 2013

The decision to use track_offsets[1] to get the offset for the first track was based on discid_get_track_offset(disc, 1).

This is kind of an 1:1 translation to the libdiscid API, but when using an array tracks we have this:
tracks[0] corresponds to track_offset[1].

Well, the problem is there anyways, since tracks[0] does have the track number 1.
The question rather is:

What is the least suprise?

for track_number in range(1, len(tracks)-1):
    print(track_offset[track_number])

or

for track_number in range(1, len(tracks)-1):
    print(track_offset[track_number-1])

Should the track_offsets be accessed by track_number or by "track_index"?

The decision in the libdiscid API and in this module currently was, that you should index by track_number and having track_*[0] to be something different a way to achieve this.

A related issue is #23 (Track objects?). That doesn't solve the index problem though.

@JonnyJD
Copy link
Owner Author

JonnyJD commented Apr 20, 2013

Well, a part of the question is:
Can the first track be something different than 1?

The standard says "The track numbering shall start with the value 01 and increment by one."
So the first track number is extracted from disc, but it should be 1 for every standard CD and musicbrainz DOES have problems when the first track wouldn't be 1. (I read a bit in the code).
This is one of the reasons why the first track is not discarded, even if it is a data track.

http://musicbrainz.org/release/046d66a3-ec8f-4d24-873f-21a11f67b0fb is the Quake game disc. First track is a data track (the game) the other 10 tracks are audio tracks.
The first track reported by the driver is still track number 1.

I'll yet have to see (even on the net) a single audio disc where the first track is not 1.

So that shouldn't be an issue.
I might however correct the code so it would technically fill the tracks before the first track. Just in case.

JonnyJD added a commit that referenced this issue Apr 20, 2013
The first track shall always be 1, though, as per the standard.
JonnyJD added a commit that referenced this issue Apr 20, 2013
The first track shall always be 1, though, as per the standard.
@JonnyJD
Copy link
Owner Author

JonnyJD commented Apr 21, 2013

One thing is a bit weird with my implementation:

for track in tracks:

directly doesn't work, since you don't want to list track 0 normally.

You are suppose to do:

for i in range(1, disc.last_track_num + 1):

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant