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

Support multiple TXXX ID3 tags #1234

Merged
merged 6 commits into from
Feb 15, 2016
Merged

Conversation

outlying
Copy link

@outlying outlying commented Feb 4, 2016

This pull request change representation of ID3 data from Map<String,Object> to Id3Tag class. Id3Tag implements Map<String,Object> for backward compability.

However for TXXX frames Id3Tag class have separate Set collection, and because of that Id3Parser was also changed to put all TXXX inside Set and not inside Map itself.

According to ID3v2.3.0 documentation "There may be more than one "TXXX" frame in each tag", previous implementation was overriding TXXX key value and in the end only last TXXX was included in Map object.

@googlebot
Copy link

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.

@outlying
Copy link
Author

outlying commented Feb 4, 2016

Error in CLA occurred because of my global Git configuration on computer I worked, what should I do in this case ? My GitHub account match in CLA but commits are using different email address

@googlebot
Copy link

CLAs look good, thanks!

@googlebot googlebot added cla: yes and removed cla: no labels Feb 4, 2016
@outlying
Copy link
Author

outlying commented Feb 4, 2016

Fixed myself

@ojw28
Copy link
Contributor

ojw28 commented Feb 10, 2016

Hi. Please could you provide some test content that requires this change? Thanks!

@outlying
Copy link
Author

Sure, we have video that contains information for mid rolls in TXXX frames http://aftonbladetlive-lh.akamaihd.net/i/20150928224817na_1@182509/master.m3u8?custom-mdt=on (don't ommit custom-mdt param) you should be able to see some extra TXXX at the beginning of this video

Because college of mine is working on iOS application, I know that extra information in TXXX frames are available. Those extra TXXX frames should contain keys like "duration" or "trigger" and those TXXX frames are there and are parsed correctly by parser but value in ID3 frames Map is constantly overwritten by last TXXX value.

@ojw28
Copy link
Contributor

ojw28 commented Feb 11, 2016

Thanks! Looking at the spec, it appears PRIV and GEOB can both be repeated as well, and for the general case we need to assume repeats are possible too.

So I think we need to come up with a representation that supports repeated frames in general. Preferably a lightweight one; I don't really want to end up with each Id3Tag being a Map<String, List>.

What about if we make Id3Parser.parse return List<Id3Frame>. Id3Frame would be an abstract base class containing the frame type as a public final String, and would be extended by PrivFrame, GeobFrame, TxxxFrame and BinaryFrame. Seems simple enough and allows arbitrary repetitions of any frame type.

@outlying
Copy link
Author

Right, it's better solution for repeated frames of various types.

I will correct this based on your suggestions, is that ok ?

@ojw28
Copy link
Contributor

ojw28 commented Feb 11, 2016

That would be great; thanks! Don't worry about backward compatibility by the way; we're generally ok with breaking compatibility for the purposes of making the library better.

@outlying
Copy link
Author

Done

public final String filename;
public final String description;
public final byte[] data;
private final String mimeType;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why have you made all of these private? We have a preference for making fields public if they're final, rather than having getter methods. Ditto in other files (including the new BinaryFrame file).

@ojw28
Copy link
Contributor

ojw28 commented Feb 12, 2016

Changes look good; thanks. Please can we go back to having public final fields though?

If you could revert the indentation changes too, and make the indentation consistent with the rest of the library, that would be great. Not to worry if you can't be bothered though; we can do it after it's merged if needed. NB - Regular indent is 2 spaces, or 4 spaces when breaking a line.

@outlying
Copy link
Author

Sure, I will correct that on Monday

@outlying
Copy link
Author

Public fields are back

@ojw28
Copy link
Contributor

ojw28 commented Feb 15, 2016

Thanks!

ojw28 added a commit that referenced this pull request Feb 15, 2016
@ojw28 ojw28 merged commit 96f39f5 into google:dev Feb 15, 2016
@outlying outlying deleted the MultipleTXXX-ID3-Tags branch February 22, 2016 10:32
@ernhelm ernhelm mentioned this pull request Feb 22, 2016
ojw28 added a commit that referenced this pull request Jun 15, 2016
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=117224172
@google google locked and limited conversation to collaborators Jun 28, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants